Transfer the ownership  转移仓库所有权 do not work in V1.90~V1.92

i loopback to v1.83,it works.

(Please forgive if I read 转移仓库所有权 incorrectly. I am using Gitea with English language settings)
Do you get a specific error why trying to use "Transfer Ownership" from the repository settings?
I just tested in https://try.gitea.io/demoorg1/iss7947 (which is actually v1.10.0 dev build), and was able to transfer this repo from myself, to be owned by a different organization.
In my personal Gitea instance running v1.9.2 I was also able to Transfer Ownership of a repository to a different username.
In the gitea.log, I think it looks something like this:
gitea.log:2019/08/31 23:40:03 ...rm/session_update.go:375:Update() [I] [SQL] UPDATE "repository" SET "owner_id" = $1, "lower_name" = $2, "name" = $3, "description" = $4, "default_branch" = $5, "num_watches" = $6, "size" = $7, "updated_unix" = $8 WHERE "id"=$9 []interface {}{6, "demorepo", "demorepo", "demo for SSH activity", "master", 1, 20480,<PHONE_NUMBER>, 5}
gitea.log:2019/08/31 23:40:03 .../xorm/session_raw.go:143:queryBytes() [I] [SQL] INSERT INTO "action" ("user_id","op_type","act_user_id","repo_id","comment_id","is_deleted","ref_name","is_private","content","created_unix") VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10) RETURNING "id" []interface {}{2, 8, 2, 5, 0, false, "", true, "demoorg/demorepo",<PHONE_NUMBER>}
gitea.log:2019/08/31 23:40:03 ...rm/session_delete.go:211:Delete() [I] [SQL] DELETE FROM "repo_redirect" WHERE "owner_id"=$1 AND "lower_name"=$2 []interface {}{6, "demorepo"}
gitea.log:2019/08/31 23:40:03 ...rm/session_delete.go:211:Delete() [I] [SQL] DELETE FROM "repo_redirect" WHERE "owner_id"=$1 AND "lower_name"=$2 []interface {}{5, "demorepo"}
gitea.log:2019/08/31 23:40:03 .../xorm/session_raw.go:143:queryBytes() [I] [SQL] INSERT INTO "repo_redirect" ("owner_id","lower_name","redirect_repo_id") VALUES ($1, $2, $3) RETURNING "id" []interface {}{5, "demorepo", 5}

I didn't encounter a problem when testing it. Hopefully your log may show some interesting messages

log on console:
[Macaron] 2019-09-06 13:44:37: Completed POST /go/XM_51SLQ/settings 500 Internal
Server Error in 27.3438ms
[Macaron] 2019-09-06 13:44:37: Started GET /img/500.png for <IP_ADDRESS>
[Macaron] [Static] Serving /img/500.png
[Macaron] 2019-09-06 13:44:37: Completed GET /img/500.png 200 OK in 0s
logfile:
2019/09/06 13:44:20 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, lower_name, name, full_name, email, keep_email_private, passwd, must_change_password, login_type, login_source, login_name, type, location, website, rands, salt, language, description, created_unix, updated_unix, last_login_unix, last_repo_visibility, max_repo_creation, is_active, is_admin, allow_git_hook, allow_import_local, allow_create_organization, prohibit_login, avatar, avatar_email, use_custom_avatar, num_followers, num_following, num_stars, num_repos, num_teams, num_members, visibility, diff_view_style, theme FROM user WHERE id=? LIMIT 1 []interface {}{1}
2019/09/06 13:44:20 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count() FROM notification WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1}
2019/09/06 13:44:20 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, owner_id, lower_name, name, description, website, default_branch, num_watches, num_stars, num_forks, num_issues, num_closed_issues, num_pulls, num_closed_pulls, num_milestones, num_closed_milestones, is_private, is_empty, is_archived, is_mirror, is_fork, fork_id, size, is_fsck_enabled, close_issues_via_commit_in_any_branch, topics, avatar, created_unix, updated_unix FROM repository WHERE owner_id=? AND lower_name=? LIMIT 1 []interface {}{1, "xm_51slq"}
2019/09/06 13:44:20 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, repo_id, user_id, mode FROM collaboration WHERE repo_id=? AND user_id=? LIMIT 1 []interface {}{34, 1}
2019/09/06 13:44:20 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT id, repo_id, type, config, created_unix FROM repo_unit WHERE (repo_id = ?) []interface {}{34}
2019/09/06 13:44:20 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count() FROM release WHERE repo_id=?  AND (team.authorize=?) ORDER BY user.name ASC []interface {}{1, 4}
2019/09/06 13:44:20 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, owner_id, lower_name, name, description, website, default_branch, num_watches, num_stars, num_forks, num_issues, num_closed_issues, num_pulls, num_closed_pulls, num_milestones, num_closed_milestones, is_private, is_empty, is_archived, is_mirror, is_fork, fork_id, size, is_fsck_enabled, close_issues_via_commit_in_any_branch, topics, avatar, created_unix, updated_unix FROM repository WHERE (owner_id=? AND fork_id=?) LIMIT 1 []interface {}{5, 34}
2019/09/06 13:44:20 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, user_id, repo_id FROM watch WHERE user_id=? AND repo_id=? LIMIT 1 []interface {}{1, 34}
2019/09/06 13:44:20 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, uid, repo_id FROM star WHERE uid=? AND repo_id=? LIMIT 1 []interface {}{1, 34}
2019/09/06 13:44:20 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT topic.* FROM topic INNER JOIN repo_topic ON repo_topic.topic_id = topic.id WHERE repo_topic.repo_id=? ORDER BY topic.repo_count DESC []interface {}{34}
2019/09/06 13:44:20 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, lower_name, name, full_name, email, keep_email_private, passwd, must_change_password, login_type, login_source, login_name, type, location, website, rands, salt, language, description, created_unix, updated_unix, last_login_unix, last_repo_visibility, max_repo_creation, is_active, is_admin, allow_git_hook, allow_import_local, allow_create_organization, prohibit_login, avatar, avatar_email, use_custom_avatar, num_followers, num_following, num_stars, num_repos, num_teams, num_members, visibility, diff_view_style, theme FROM user WHERE email=? LIMIT 1 []interface<EMAIL_ADDRESS>2019/09/06 13:44:20 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT max( id ) as id FROM commit_status WHERE (repo_id = ?) AND (sha = ?) GROUP BY context_hash ORDER BY max( id ) desc LIMIT 10 []interface {}{34, "b8ce9d60fa5d3e3b9cbd8ab77374e4c8f1883596"}
2019/09/06 13:44:27 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, lower_name, name, full_name, email, keep_email_private, passwd, must_change_password, login_type, login_source, login_name, type, location, website, rands, salt, language, description, created_unix, updated_unix, last_login_unix, last_repo_visibility, max_repo_creation, is_active, is_admin, allow_git_hook, allow_import_local, allow_create_organization, prohibit_login, avatar, avatar_email, use_custom_avatar, num_followers, num_following, num_stars, num_repos, num_teams, num_members, visibility, diff_view_style, theme FROM user WHERE id=? LIMIT 1 []interface {}{1}
2019/09/06 13:44:27 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count() FROM notification WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1}
2019/09/06 13:44:27 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, owner_id, lower_name, name, description, website, default_branch, num_watches, num_stars, num_forks, num_issues, num_closed_issues, num_pulls, num_closed_pulls, num_milestones, num_closed_milestones, is_private, is_empty, is_archived, is_mirror, is_fork, fork_id, size, is_fsck_enabled, close_issues_via_commit_in_any_branch, topics, avatar, created_unix, updated_unix FROM repository WHERE owner_id=? AND lower_name=? LIMIT 1 []interface {}{1, "xm_51slq"}
2019/09/06 13:44:27 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, repo_id, user_id, mode FROM collaboration WHERE repo_id=? AND user_id=? LIMIT 1 []interface {}{34, 1}
2019/09/06 13:44:27 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT id, repo_id, type, config, created_unix FROM repo_unit WHERE (repo_id = ?) []interface {}{34}
2019/09/06 13:44:27 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count() FROM release WHERE repo_id=?  AND (team.authorize=?) ORDER BY user.name ASC []interface {}{1, 4}
2019/09/06 13:44:27 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, owner_id, lower_name, name, description, website, default_branch, num_watches, num_stars, num_forks, num_issues, num_closed_issues, num_pulls, num_closed_pulls, num_milestones, num_closed_milestones, is_private, is_empty, is_archived, is_mirror, is_fork, fork_id, size, is_fsck_enabled, close_issues_via_commit_in_any_branch, topics, avatar, created_unix, updated_unix FROM repository WHERE (owner_id=? AND fork_id=?) LIMIT 1 []interface {}{5, 34}
2019/09/06 13:44:27 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, user_id, repo_id FROM watch WHERE user_id=? AND repo_id=? LIMIT 1 []interface {}{1, 34}
2019/09/06 13:44:27 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, uid, repo_id FROM star WHERE uid=? AND repo_id=? LIMIT 1 []interface {}{1, 34}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, lower_name, name, full_name, email, keep_email_private, passwd, must_change_password, login_type, login_source, login_name, type, location, website, rands, salt, language, description, created_unix, updated_unix, last_login_unix, last_repo_visibility, max_repo_creation, is_active, is_admin, allow_git_hook, allow_import_local, allow_create_organization, prohibit_login, avatar, avatar_email, use_custom_avatar, num_followers, num_following, num_stars, num_repos, num_teams, num_members, visibility, diff_view_style, theme FROM user WHERE id=? LIMIT 1 []interface {}{1}
2019/09/06 13:44:37 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count() FROM notification WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, owner_id, lower_name, name, description, website, default_branch, num_watches, num_stars, num_forks, num_issues, num_closed_issues, num_pulls, num_closed_pulls, num_milestones, num_closed_milestones, is_private, is_empty, is_archived, is_mirror, is_fork, fork_id, size, is_fsck_enabled, close_issues_via_commit_in_any_branch, topics, avatar, created_unix, updated_unix FROM repository WHERE owner_id=? AND lower_name=? LIMIT 1 []interface {}{1, "xm_51slq"}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, repo_id, user_id, mode FROM collaboration WHERE repo_id=? AND user_id=? LIMIT 1 []interface {}{34, 1}
2019/09/06 13:44:37 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT id, repo_id, type, config, created_unix FROM repo_unit WHERE (repo_id = ?) []interface {}{34}
2019/09/06 13:44:37 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count() FROM release WHERE repo_id=?  AND (team.authorize=?) ORDER BY user.name ASC []interface {}{1, 4}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, owner_id, lower_name, name, description, website, default_branch, num_watches, num_stars, num_forks, num_issues, num_closed_issues, num_pulls, num_closed_pulls, num_milestones, num_closed_milestones, is_private, is_empty, is_archived, is_mirror, is_fork, fork_id, size, is_fsck_enabled, close_issues_via_commit_in_any_branch, topics, avatar, created_unix, updated_unix FROM repository WHERE (owner_id=? AND fork_id=?) LIMIT 1 []interface {}{5, 34}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, user_id, repo_id FROM watch WHERE user_id=? AND repo_id=? LIMIT 1 []interface {}{1, 34}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, uid, repo_id FROM star WHERE uid=? AND repo_id=? LIMIT 1 []interface {}{1, 34}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, lower_name, name, full_name, email, keep_email_private, passwd, must_change_password, login_type, login_source, login_name, type, location, website, rands, salt, language, description, created_unix, updated_unix, last_login_unix, last_repo_visibility, max_repo_creation, is_active, is_admin, allow_git_hook, allow_import_local, allow_create_organization, prohibit_login, avatar, avatar_email, use_custom_avatar, num_followers, num_following, num_stars, num_repos, num_teams, num_members, visibility, diff_view_style, theme FROM user WHERE (id!=?) AND lower_name=? LIMIT 1 []interface {}{0, "ximo"}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, lower_name, name, full_name, email, keep_email_private, passwd, must_change_password, login_type, login_source, login_name, type, location, website, rands, salt, language, description, created_unix, updated_unix, last_login_unix, last_repo_visibility, max_repo_creation, is_active, is_admin, allow_git_hook, allow_import_local, allow_create_organization, prohibit_login, avatar, avatar_email, use_custom_avatar, num_followers, num_following, num_stars, num_repos, num_teams, num_members, visibility, diff_view_style, theme FROM user WHERE lower_name=? LIMIT 1 []interface {}{"ximo"}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, owner_id, lower_name, name, description, website, default_branch, num_watches, num_stars, num_forks, num_issues, num_closed_issues, num_pulls, num_closed_pulls, num_milestones, num_closed_milestones, is_private, is_empty, is_archived, is_mirror, is_fork, fork_id, size, is_fsck_enabled, close_issues_via_commit_in_any_branch, topics, avatar, created_unix, updated_unix FROM repository WHERE owner_id=? AND lower_name=? LIMIT 1 []interface {}{2, "xm_51slq"}
2019/09/06 13:44:37 ...xorm/xorm/session.go:845:saveLastSQL() [I] [SQL] BEGIN TRANSACTION
2019/09/06 13:44:37 ...rm/session_update.go:375:Update() [I] [SQL] UPDATE repository SET owner_id = ?, lower_name = ?, name = ?, description = ?, default_branch = ?, num_watches = ?, size = ?, updated_unix = ? WHERE id=? []interface {}{2, "xm_51slq", "XM_51SLQ", "鏂板攼51鍗曠墖鏈虹儳鍐欏櫒LED鐘舵€佽浆鎹㈠櫒", "master", 1, 1158144,<PHONE_NUMBER>, 34}
2019/09/06 13:44:37 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT id, repo_id, user_id, mode FROM collaboration WHERE repo_id=? []interface {}{34}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, org_id, lower_name, name, description, authorize, num_repos, num_members FROM team WHERE org_id=? AND lower_name=? LIMIT 1 []interface {}{2, "owners"}
2019/09/06 13:44:37 ...rm/session_insert.go:513:innerInsert() [I] [SQL] INSERT INTO team_repo (org_id,team_id,repo_id) VALUES (?, ?, ?) []interface {}{2, 1, 34}
2019/09/06 13:44:37 ...rm/session_update.go:375:Update() [I] [SQL] UPDATE team SET num_repos = num_repos + ? WHERE id=? []interface {}{1, 1}
2019/09/06 13:44:37 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT id, repo_id, user_id, mode FROM collaboration WHERE repo_id=? []interface {}{34}
2019/09/06 13:44:37 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT id, org_id, lower_name, name, description, authorize, num_repos, num_members FROM team WHERE (org_id=?)  LIMIT 1 []interface {}{1}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, lower_name, name, full_name, email, keep_email_private, passwd, must_change_password, login_type, login_source, login_name, type, location, website, rands, salt, language, description, created_unix, updated_unix, last_login_unix, last_repo_visibility, max_repo_creation, is_active, is_admin, allow_git_hook, allow_import_local, allow_create_organization, prohibit_login, avatar, avatar_email, use_custom_avatar, num_followers, num_following, num_stars, num_repos, num_teams, num_members, visibility, diff_view_style, theme FROM user WHERE id=? LIMIT 1 []interface {}{3}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, lower_name, name, full_name, email, keep_email_private, passwd, must_change_password, login_type, login_source, login_name, type, location, website, rands, salt, language, description, created_unix, updated_unix, last_login_unix, last_repo_visibility, max_repo_creation, is_active, is_admin, allow_git_hook, allow_import_local, allow_create_organization, prohibit_login, avatar, avatar_email, use_custom_avatar, num_followers, num_following, num_stars, num_repos, num_teams, num_members, visibility, diff_view_style, theme FROM user WHERE id=?  LIMIT 1 []interface {}{1}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, lower_name, name, full_name, email, keep_email_private, passwd, must_change_password, login_type, login_source, login_name, type, location, website, rands, salt, language, description, created_unix, updated_unix, last_login_unix, last_repo_visibility, max_repo_creation, is_active, is_admin, allow_git_hook, allow_import_local, allow_create_organization, prohibit_login, avatar, avatar_email, use_custom_avatar, num_followers, num_following, num_stars, num_repos, num_teams, num_members, visibility, diff_view_style, theme FROM user WHERE id=? LIMIT 1 []interface {}{3}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, lower_name, name, full_name, email, keep_email_private, passwd, must_change_password, login_type, login_source, login_name, type, location, website, rands, salt, language, description, created_unix, updated_unix, last_login_unix, last_repo_visibility, max_repo_creation, is_active, is_admin, allow_git_hook, allow_import_local, allow_create_organization, prohibit_login, avatar, avatar_email, use_custom_avatar, num_followers, num_following, num_stars, num_repos, num_teams, num_members, visibility, diff_view_style, theme FROM user WHERE id=? LIMIT 1 []interface {}{6}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, user_id, repo_id FROM watch WHERE user_id=? AND repo_id=? LIMIT 1 []interface {}{6, 34}
2019/09/06 13:44:37 ...rm/session_insert.go:513:innerInsert() [I] [SQL] INSERT INTO watch (user_id,repo_id) VALUES (?, ?) []interface {}{6, 34}
2019/09/06 13:44:37 .../xorm/session_raw.go:226:Exec() [I] [SQL] UPDATE repository SET num_watches = num_watches + 1 WHERE id = ? []interface {}{34}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, user_id, repo_id FROM watch WHERE user_id=? AND repo_id=? LIMIT 1 []interface {}{3, 34}
2019/09/06 13:44:37 ...rm/session_insert.go:513:innerInsert() [I] [SQL] INSERT INTO watch (user_id,repo_id) VALUES (?, ?) []interface {}{3, 34}
2019/09/06 13:44:37 .../xorm/session_raw.go:226:Exec() [I] [SQL] UPDATE repository SET num_watches = num_watches + 1 WHERE id = ? []interface {}{34}
2019/09/06 13:44:37 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT id, user_id, repo_id FROM watch WHERE user_id=? AND repo_id=?  AND repo_id=? LIMIT 1 []interface {}{1, 34}
2019/09/06 13:44:37 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT * FROM watch INNER JOIN user ON user.id = watch.user_id WHERE (watch.repo_id=?) AND (user.is_active=?)

Maybe you should not store you gitea data on C:\ on windows since it's a system disk

@lunny I'm experiencing frequent 500 errors after transferring repos to an organization.
This is recent as I upgraded to Gitea 1.9.2 just last week and coincides with the 500s.
I'm currently resolving this by stoping and restarting my gitea service installd on Raspbian (raspberry pi, arm7).

@lunny I'm experiencing frequent 500 errors after transferring repos to an organization.
This is recent as I upgraded to Gitea 1.9.2 just last week and coincides with the 500s.
I'm currently resolving this by stoping and restarting my gitea service installd on Raspbian (raspberry pi, arm7).

A "500 error" is a generic code meaning "something unexpected happened". It would be very useful if you could paste here a relevant part of your gitea.log from the moment the error happened.

Here is a log right after getting my 500 errors:
2019/09/07 14:07:32 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `repo_id`, `index`, `poster_id`, `name`, `content`, `milestone_id`, `priority`, `is_closed`, `is_pull`, `num_comments`, `ref`, `deadline_unix`, `created_unix`, `updated_unix`, `closed_unix`, `is_locked` FROM `issue` WHERE `repo_id`=? AND `index`=? LIMIT 1 []interface {}{40, 20}
2019/09/07 14:07:32 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `repo_id`, `index`, `poster_id`, `name`, `content`, `milestone_id`, `priority`, `is_closed`, `is_pull`, `num_comments`, `ref`, `deadline_unix`, `created_unix`, `updated_unix`, `closed_unix`, `is_locked` FROM `issue` WHERE `repo_id`=? AND `index`=?   LIMIT 1 []interface<EMAIL_ADDRESS>2019/09/07 14:07:32 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `repo_id`, `index`, `poster_id`, `name`, `content`, `milestone_id`, `priority`, `is_closed`, `is_pull`, `num_comments`, `ref`, `deadline_unix`, `created_unix`, `updated_unix`, `closed_unix`, `is_locked` FROM `issue` WHERE `repo_id`=? AND `index`=? LIMIT 1 []interface {}{50, 28}
2019/09/07 14:07:32 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `type`, `poster_id`, `issue_id`, `label_id`, `old_milestone_id`, `milestone_id`, `assignee_id`, `removed_assignee`, `old_title`, `new_title`, `dependent_issue_id`, `commit_id`, `line`, `tree_path`, `content`, `patch`, `created_unix`, `updated_unix`, `commit_sha`, `review_id`, `invalidated` FROM `comment` WHERE `id`=? LIMIT 1 []interface {}{2280}
2019/09/07 14:07:32 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `repo_id`, `index`, `poster_id`, `name`, `content`, `milestone_id`, `priority`, `is_closed`, `is_pull`, `num_comments`, `ref`, `deadline_unix`, `created_unix`, `updated_unix`, `closed_unix`, `is_locked` FROM `issue` WHERE `id`=?  LIMIT 1 []interface {}{50}
2019/09/07 14:07:32 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `name` FROM `user` WHERE `id`=? LIMIT 1 []interface {}{3}
2019/09/07 14:07:32 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `repo_id`, `index`, `poster_id`, `name`, `content`, `milestone_id`, `priority`, `is_closed`, `is_pull`, `num_comments`, `ref`, `deadline_unix`, `created_unix`, `updated_unix`, `closed_unix`, `is_locked` FROM `issue` WHERE `repo_id`=? AND `index`=?         LIMIT 1 []interface<EMAIL_ADDRESS>2019/09/07 14:07:32 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `repo_id`, `index`, `poster_id`, `name`, `content`, `milestone_id`, `priority`, `is_closed`, `is_pull`, `num_comments`, `ref`, `deadline_unix`, `created_unix`, `updated_unix`, `closed_unix`, `is_locked` FROM `issue` WHERE `repo_id`=? AND `index`=?   LIMIT 1 []interface {}{"louis"}
2019/09/07 14:07:34 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT UNIX_TIMESTAMP(DATE(FROM_UNIXTIME(created_unix))) AS timestamp, count(user_id) as contributions FROM `action` WHERE (user_id = ?) AND (created_unix > ?) AND (act_user_id = ?) GROUP BY timestamp ORDER BY timestamp []interface {}{1,<PHONE_NUMBER>, 1}
2019/09/07 14:07:34 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `id`=? LIMIT 1 []interface {}{1}
2019/09/07 14:07:34 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count(*) FROM `repository` WHERE (owner_id=? OR (((repository.id IN (SELECT repo_id FROM `access` WHERE access.user_id = ?)) OR id IN (SELECT `team_repo`.repo_id FROM team_repo INNER JOIN team_user ON `team_user`.team_id = `team_repo`.team_id WHERE `team_user`.uid=?)) AND owner_id<>?)) []interface {}{1, 1, 1, 1}
2019/09/07 14:07:35 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT `id`, `owner_id`, `lower_name`, `name`, `description`, `website`, `default_branch`, `num_watches`, `num_stars`, `num_forks`, `num_issues`, `num_closed_issues`, `num_pulls`, `num_closed_pulls`, `num_milestones`, `num_closed_milestones`, `is_private`, `is_empty`, `is_archived`, `is_mirror`, `is_fork`, `fork_id`, `size`, `is_fsck_enabled`, `close_issues_via_commit_in_any_branch`, `topics`, `avatar`, `created_unix`, `updated_unix` FROM `repository` WHERE (owner_id=? OR (((repository.id IN (SELECT repo_id FROM `access` WHERE access.user_id = ?)) OR id IN (SELECT `team_repo`.repo_id FROM team_repo INNER JOIN team_user ON `team_user`.team_id = `team_repo`.team_id WHERE `team_user`.uid=?)) AND owner_id<>?)) ORDER BY updated_unix DESC LIMIT 15 []interface {}{1, 1, 1, 1}
2019/09/07 14:07:35 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE (id > 0) AND `id` IN (?,?) []interface {}{3, 1}
2019/09/07 14:07:35 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `repo_id`, `user_id`, `mode` FROM `collaboration` WHERE `repo_id`=? AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  AND `user_id`=?  LIMIT 1 []interface {}{1}
2019/09/07 14:07:35 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count(*) FROM `notification` WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1}
2019/09/07 14:07:41 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `lower_name`=?  AND `lower_name`=? LIMIT 1 []interface {}{1, "phi3250-h19-travail-2"}
2019/09/07 14:07:41 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `owner_id`, `lower_name`, `redirect_repo_id` FROM `repo_redirect` WHERE `owner_id`=? AND `lower_name`=?  LIMIT 1 []interface {}{26}
2019/09/07 14:07:41 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `name` FROM `user` WHERE `id`=?   AND `lower_name`=?  AND is_draft=? []interface {}{26, false}
2019/09/07 14:07:42 ...ules/context/repo.go:664:func1() [E] GetCommitsCount: fork/exec /usr/bin/git: cannot allocate memory
2019/09/07 14:07:54 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `id`=? LIMIT 1 []interface {}{1}
2019/09/07 14:07:54 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count(*) FROM `notification` WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1}
2019/09/07 14:07:54 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `lower_name`=?  AND `lower_name`=? LIMIT 1 []interface {}{3, "fra3310-a19-notes"}
2019/09/07 14:07:54 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `repo_id`, `user_id`, `mode` FROM `collaboration` WHERE `repo_id`=? AND `user_id`=?  AND is_draft=? []interface {}{40, false}
2019/09/07 14:07:54 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `owner_id`, `lower_name`, `name`, `description`, `website`, `default_branch`, `num_watches`, `num_stars`, `num_forks`, `num_issues`, `num_closed_issues`, `num_pulls`, `num_closed_pulls`, `num_milestones`, `num_closed_milestones`, `is_private`, `is_empty`, `is_archived`, `is_mirror`, `is_fork`, `fork_id`, `size`, `is_fsck_enabled`, `close_issues_via_commit_in_any_branch`, `topics`, `avatar`, `created_unix`, `updated_unix` FROM `repository` WHERE (owner_id=? AND fork_id=?) LIMIT 1 []interface {}{1, 40}
2019/09/07 14:07:54 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `user_id`, `repo_id` FROM `watch` WHERE `user_id`=? AND `repo_id`=? LIMIT 1 []interface {}{1, 40}
2019/09/07 14:07:54 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `uid`, `repo_id` FROM `star` WHERE `uid`=? AND `repo_id`=? LIMIT 1 []interface {}{1, 40}
2019/09/07 14:07:54 ...ules/context/repo.go:664:func1() [E] GetCommitsCount: fork/exec /usr/bin/git: cannot allocate memory
2019/09/07 14:07:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `id`=? LIMIT 1 []interface {}{1}
2019/09/07 14:07:55 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count(*) FROM `notification` WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1}
2019/09/07 14:07:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `owner_id`, `lower_name`, `name`, `description`, `website`, `default_branch`, `num_watches`, `num_stars`, `num_forks`, `num_issues`, `num_closed_issues`, `num_pulls`, `num_closed_pulls`, `num_milestones`, `num_closed_milestones`, `is_private`, `is_empty`, `is_archived`, `is_mirror`, `is_fork`, `fork_id`, `size`, `is_fsck_enabled`, `close_issues_via_commit_in_any_branch`, `topics`, `avatar`, `created_unix`, `updated_unix` FROM `repository` WHERE `owner_id`=? AND `lower_name`=? LIMIT 1 []interface {}{1, "gitea-stuff"}
2019/09/07 14:07:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `repo_id`, `user_id`, `mode` FROM `collaboration` WHERE `repo_id`=? AND `user_id`=?   AND (`team`.authorize=?) ORDER BY `user`.`name` ASC []interface {}{1, 4}
2019/09/07 14:07:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `owner_id`, `lower_name`, `name`, `description`, `website`, `default_branch`, `num_watches`, `num_stars`, `num_forks`, `num_issues`, `num_closed_issues`, `num_pulls`, `num_closed_pulls`, `num_milestones`, `num_closed_milestones`, `is_private`, `is_empty`, `is_archived`, `is_mirror`, `is_fork`, `fork_id`, `size`, `is_fsck_enabled`, `close_issues_via_commit_in_any_branch`, `topics`, `avatar`, `created_unix`, `updated_unix` FROM `repository` WHERE (owner_id=? AND fork_id=?) LIMIT 1 []interface {}{2, 41}
2019/09/07 14:07:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `user_id`, `repo_id` FROM `watch` WHERE `user_id`=? AND `repo_id`=? LIMIT 1 []interface {}{1, 41}
2019/09/07 14:07:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `uid`, `repo_id` FROM `star` WHERE `uid`=? AND `repo_id`=? LIMIT 1 []interface {}{1, 41}
2019/09/07 14:07:55 ...ules/context/repo.go:664:func1() [E] GetCommitsCount: fork/exec /usr/bin/git: cannot allocate memory
2019/09/07 14:07:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `id`=? LIMIT 1 []interface {}{1}
2019/09/07 14:07:55 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count(*) FROM `notification` WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1}
2019/09/07 14:07:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `lower_name`=?  AND `lower_name`=? LIMIT 1 []interface {}{3, "fra3314-a19-notes"}
2019/09/07 14:07:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `repo_id`, `user_id`, `mode` FROM `collaboration` WHERE `repo_id`=? AND `user_id`=?  AND is_draft=? []interface {}{50, false}
2019/09/07 14:07:56 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `owner_id`, `lower_name`, `name`, `description`, `website`, `default_branch`, `num_watches`, `num_stars`, `num_forks`, `num_issues`, `num_closed_issues`, `num_pulls`, `num_closed_pulls`, `num_milestones`, `num_closed_milestones`, `is_private`, `is_empty`, `is_archived`, `is_mirror`, `is_fork`, `fork_id`, `size`, `is_fsck_enabled`, `close_issues_via_commit_in_any_branch`, `topics`, `avatar`, `created_unix`, `updated_unix` FROM `repository` WHERE (owner_id=? AND fork_id=?) LIMIT 1 []interface {}{1, 50}
2019/09/07 14:07:56 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `user_id`, `repo_id` FROM `watch` WHERE `user_id`=? AND `repo_id`=? LIMIT 1 []interface {}{1, 50}
2019/09/07 14:07:56 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `uid`, `repo_id` FROM `star` WHERE `uid`=? AND `repo_id`=? LIMIT 1 []interface {}{1, 50}
2019/09/07 14:07:56 ...ules/context/repo.go:664:func1() [E] GetCommitsCount: fork/exec /usr/bin/git: cannot allocate memory
2019/09/07 14:07:56 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `id`=? LIMIT 1 []interface {}{1}
2019/09/07 14:07:56 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count(*) FROM `notification` WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1}
2019/09/07 14:07:56 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `id`=? LIMIT 1 []interface {}{1}
2019/09/07 14:07:56 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count(*) FROM `notification` WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1}
2019/09/07 14:07:57 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `id`=? LIMIT 1 []interface {}{1}
2019/09/07 14:07:57 .../xorm/session_raw.go:87:queryRow() [I] [SQL] SELECT count(*) FROM `notification` WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1}
2019/09/07 14:08:20 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `lower_name`=?  AND `lower_name`=? LIMIT 1 []interface {}{1, "phi2180-notes-h19"}
2019/09/07 14:08:20 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `owner_id`, `lower_name`, `redirect_repo_id` FROM `repo_redirect` WHERE `owner_id`=? AND `lower_name`=?  LIMIT 1 []interface {}{23}
2019/09/07 14:08:20 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `name` FROM `user` WHERE `id`=?   AND `lower_name`=?  AND is_draft=? []interface {}{23, false}
2019/09/07 14:08:21 ...ules/context/repo.go:664:func1() [E] GetCommitsCount: fork/exec /usr/bin/git: cannot allocate memory
2019/09/07 14:08:30 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `lower_name`=?  AND `lower_name`=?  AND is_draft=? []interface {}{37, false}
2019/09/07 14:08:30 ...ules/context/repo.go:664:func1() [E] GetCommitsCount: fork/exec /usr/bin/git: cannot allocate memory
2019/09/07 14:08:49 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `lower_name`=? LIMIT 1 []interface {}{"louis"}
2019/09/07 14:08:49 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `owner_id`, `lower_name`, `name`, `description`, `website`, `default_branch`, `num_watches`, `num_stars`, `num_forks`, `num_issues`, `num_closed_issues`, `num_pulls`, `num_closed_pulls`, `num_milestones`, `num_closed_milestones`, `is_private`, `is_empty`, `is_archived`, `is_mirror`, `is_fork`, `fork_id`, `size`, `is_fsck_enabled`, `close_issues_via_commit_in_any_branch`, `topics`, `avatar`, `created_unix`, `updated_unix` FROM `repository` WHERE `owner_id`=? AND `lower_name`=? LIMIT 1 []interface {}{1, "phi3250-h19-travail-recherche"}
2019/09/07 14:08:49 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `owner_id`, `lower_name`, `redirect_repo_id` FROM `repo_redirect` WHERE `owner_id`=? AND `lower_name`=? LIMIT 1 []interface {}{1, "phi3250-h19-travail-recherche"}
2019/09/07 14:08:49 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `owner_id`, `lower_name`, `name`, `description`, `website`, `default_branch`, `num_watches`, `num_stars`, `num_forks`, `num_issues`, `num_closed_issues`, `num_pulls`, `num_closed_pulls`, `num_milestones`, `num_closed_milestones`, `is_private`, `is_empty`, `is_archived`, `is_mirror`, `is_fork`, `fork_id`, `size`, `is_fsck_enabled`, `close_issues_via_commit_in_any_branch`, `topics`, `avatar`, `created_unix`, `updated_unix` FROM `repository` WHERE `id`=? LIMIT 1 []interface {}{12}
2019/09/07 14:08:49 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `name` FROM `user` WHERE `id`=?   AND `lower_name`=?  AND is_draft=? []interface {}{12, false}
2019/09/07 14:08:51 ...ules/context/repo.go:664:func1() [E] GetCommitsCount: fork/exec /usr/bin/git: cannot allocate memory

Seems like you are running out of memory

@lafriks any suggestion on how to resolve this? That's what I thought, so I searched the Gitea documentation for options to configure memory limit on my gitea installation, but I found no option.
I am experiencing this only on repos recently transferred to an organization (old repos are fine).

@loup-brun Perhaps those repos have other issues besides having been recently transferred. Are they big? Have many files? Many commits? You could try running some git commands on them yourself directly from the shell and see what happens. For instance, there is git-fsck that does some sanity checks. Gitea can do git-fsck itself, but if you doubt Gitea it could be nice to have a "second opinion" directly from git.
Also, make sure to use the same user as Gitea for those tests. The root user, for instance, will not have the same restrictions in resource usage.

Small repos (max 4 MB), few files, max 10 commits. Only new projects (created since I updated to Gitea 1.9.2 from 1.8), which is why I suspect it has something to do with the update.
(old repos created before the update not affected by this bug)

@guillep2k Small repos (max 4 MB), few files, max 10 commits. Only new projects (created since I updated to Gitea 1.9.2 from 1.8), which is why I suspect it has something to do with the update.
(old repos created before the update not affected by this bug)

@loup-brun It wouldn't hurt checking them anyway. Could they have become corrupted somehow?

If you are interested, the standard procedure in my company is for the dev to create the repository, have some structural work done and then transfer it to the company org. We are using 1.9.2 without problems so far.

@loup-brun what's your git version and how did you install it?

@guillep2k I run git fsck without any problem (and have this feature turned on in Gitea).
@lunny I have git version 2.11.0 installed.
I simply update my gitea by replacing the binary /usr/local/bin/gitea (with appropriate group/file permissions) and restarting the gitea service.
I rolled back to gitea 1.8.3 (just like @gwnpeter) which works fine, no error whatsoever on those repos which I transferred ownership (tested them all several times a day for 2-3 days now).

On Windows, seems that some file still locked during os.Rename

The file object\XXXXXXXXXXXXXXXXXXXXXX.pack still locked

This looks like a concurrency problem, and IMHO difficult to solve in a bulletproof way. You have more than one process accessing the repo at the time of migration, so the migration code fails.
If you think your users are not accessing it, please check whether any automated tool either is running things on it or left processes behind locking the file. In Windows I've found that Process Explorer (a Microsoft official utility) has a search handle function that tells you which processes have a particular file open. It may be of help.
Another related and very useful utility (you can check that out) is Process Monitor, although it's a bit more difficult to use. You need to set up the filters to log only the pahts you're interested in.

I've tried with Process Monitor, pack file is locked by gitea.exe. I've put a 30sec pause before the rename, close the locked file with Process Monitor and after the pause, the repository is transfered right

I think that some git operation was transferred from git to a go library (go-git?) in 1.9.0. Perhaps that library does some caching or needs some garbage collection in order to free the files?
@nikybiasion Please try the following: remove the delay from the code, but wait in the UI 30 seconds before pressing the last confirmation button. If the problem goes away, it means that the lock is produced in some operation from the page rendered before.

Another interesting test is placing the 30s delay in different parts of the code, from the earliest point to the latest (you know that one works), until we find the point that is introducing the lock. BTW good catch!

if i go to transfer page, wait until the lock disapper, click transfer, i get 500 error and the pack file became locked.

if i go to transfer page, wait until the lock disapper, click transfer, i get 500 error and the pack file became locked.

Good to know; if you can confirm that no other accesses were being made to that repo, that should tell us that Gitea is locking itself withing the transfer procedure. That certainly shortens the search.

Same issue for me.
Windows 7 Pro SP1
SQLite version 3.30.1 2019-10-10 20:19:45
gitea-1.9.4-windows-4.0-amd64
Log Extract
s`, `num_pulls`, `num_closed_pulls`, `num_milestones`, `num_closed_milestones`, `is_private`, `is_empty`, `is_archived`, `is_mirror`, `is_fork`, `fork_id`, `size`, `is_fsck_enabled`, `close_issues_via_commit_in_any_branch`, `topics`, `avatar`, `created_unix`, `updated_unix` FROM `repository` WHERE `owner_id`=? AND `lower_name`=? LIMIT 1 []interface {}{1, "myrepo"}
2019/10/17 10:20:06 ...xorm/xorm/session.go:845:saveLastSQL() [I] [SQL] BEGIN TRANSACTION
2019/10/17 10:20:06 ...rm/session_update.go:375:Update() [I] [SQL] UPDATE `repository` SET `owner_id` = ?, `lower_name` = ?, `name` = ?, `default_branch` = ?, `num_watches` = ?, `size` = ?, `updated_unix` = ?  AND `repo_id`=? LIMIT 1 []interface {}{2, 2}
2019/10/17 10:20:06 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT * FROM `watch` INNER JOIN `user` ON `user`.id = `watch`.user_id WHERE (`watch`.repo_id=?) AND (`user`.is_active=?)

I workaround by

delete repo for philibe in gitea,
recreate empty repo in gitea for admin1,
and git push to admin1 (from command line linux).

Have you installed antivirus software and enabled it? If that, could you try disable it and try again?

@lunny I'm experiencing the same issue (see #8565), I'm not running any AV software.

@realslacker Perhaps Tortoise or another local git helper that it's integrated with Windows shell?

You can use process monitor from Microsoft's sysinternals to try and find what process is holding up the files:

I'd use a filter like this:

This should tell us which other program might be locking the directory, or is it Gitea itself.

The only service on the server is Gitea. This server is a brand new VM spun up for Gitea and I experienced this issue when moving a repo that was freshly imported into the wrong account.

The only service on the server is Gitea. This server is a brand new VM spun up for Gitea and I experienced this issue when moving a repo that was freshly imported into the wrong account.

@realslacker I was hoping to check whether the locker was Gitea's service process or a child from it (e.g. some lingering git that should not be there).

I think it's problem with windows permission granting to gitea executable. i tried running as service and also manually as administrator but got the same access denied.

I think it's problem with windows permission granting to gitea executable. i tried running as service and also manually as administrator but got the same access denied.

The error message is misleading (although it comes from Windows itself). It's almost certainly a file locking problem. We only couldn't find out in what step the directory becomes locked/fails to be released yet. Most UNIX-like filesystems don't care about file/dir locking for renaming/moving, but Windows does.

Now registering as service is giving me error 193 0x3 on service starting

Is there a way to do it manually or a workaround? (Like forking, then deleting the original?)

Is there a way to do it manually or a workaround? (Like forking, then deleting the original?)

I followed the tip from gwnpeter at the top, downgrading to v1.8.3. I then did all the transfering I needed to do, and upgraded back to v1.9.4.

I've tried with Process Monitor, pack file is locked by gitea.exe. I've put a 30sec pause before the rename, close the locked file with Process Monitor and after the pause, the repository is transfered right

First of all I must say that I couldn't reproduce the problem (Windows 10, 1.11.0+dev-141-g484edb758). However, I'm just noticing this important part of @nikybiasion 's comment: "pack file".
Now I'm thinking:

There's some lock on the repository directory or below that is triggering the problem. I think this is settled.
"Pack file" suggests it's not the directory itself that is locked, but one of the git pack files (although @nikybiasion is clear about this, we don't know if this is true for all cases).
models.TransferOwnership() performs no git operation whatsoever!

So, I think the cause is completely unrelated to the transfer itself. It only happens to affect repo ownership transfer because that operation requires moving the repository folder. Possible causes:

Multiple users accessing the repo at the time; the repo home page, code reviewing, cloning, etc.
Some git hook in operation (unrelated to the transfer).

For example, I follow this path:
func git.OpenRepository() ...
{
    storage := filesystem.NewStorageWithOptions(fs,  ...
    gogitRepo, err := gogit.Open(storage, fs) ....
    return &Repository{
        Path:         repoPath,
        gogitRepo:    gogitRepo,
        gogitStorage: storage,
        tagCache:     newObjectCache(),
    }, nil
}

func models.GetActivityStats() ....
{
    ....
    gitRepo, err := git.OpenRepository(repo.RepoPath())
    // (gitRepo not explicitly destroyed/disposed)
    ....
}

GetActivityStats() is just the first function I've found calling OpenRepository(); there may be many more. Is it possible that operations like this will keep the repo files open due to lazy garbage collection? Linux users won't notice, but Windows users will. And it will not be easy to reproduce in a simple test installation with only a couple of repositories and a single user.

Hmm might it make sense to run a git gc just before moving the git repository? I'm not sure what gc does when a pack file is locked but I think it waits. If so after the GC is done all locks should have been released and you should be able to move the repo.
The only option I can think of is to fully clone the repo on Windows and do a deferred delete perhaps using the git gc trick above to ensure that when it finishes you're hopefully ready to delete.
Because of our file system architecture with a move its possible on all systems that a transfer of a busy repo could lead to failures of pushes, be those from web edits, merges or external. On Linux that could lead to dangling objects, on windows they should just disappear in to the ether.
The only true way to prevent this from ever happening is that repos are stored by their immutable ID. Cloning would prevent that inconsistent data but would not allow ongoing actions to succeed.

As an aside if we did move to the id approach described above to help users recover from inevitable crashes the .git/config file should be updated to contain the real name and owner of the repository.
I think we could generally further (ab)use our git repositories to store more of our basic information to help people restore from failures.
Even more crazy: The git object db and references are just a hash object store - there's nothing that says you have to store only source files in there, issues and comments could all be there. There's a surprising number of people who manage to hose their DBs.

My input based on my situation:

Fresh gitea installation (<36 hours old)
Beside myself, no other users
Code indexing enabled
Repository in question was imported >24 hours ago

So, I think the cause is completely unrelated to the transfer itself. It only happens to affect repo ownership transfer because that operation requires moving the repository folder. Possible causes:
* Multiple users accessing the repo at the time; the repo home page, code reviewing, cloning, etc.

I think that is ruled out, because I was the only one using the system (we are in de pre-steps of migrating from SVN to git).

* Some git hook in operation (unrelated to the transfer).

No commits beside the initial import (git --mirror push <path to git svn cloned repo>). No hooks have also been made.

* **_(My bet)_** Some garbage collection is holding up an opened file.

That or the code indexing operation I think. But it is always happens. I haven't checked whether I can do it via the API, perhaps it would work then.

I'm also the only user of my Gitea installation. The repositories in question were moved from SVN the same day. I  decided right away I had to partition the repos into 2 organizations. About half the repos transfered ownership without problems. I could not identify any similarities between the ones that didn't, but it was consistently the same repos that had the problem. I could transfer the other ones back and forth multiple times without issue. Restarting the Gitea service didn't help. I used process explorer on a couple of the attempted transfers, and all of them created a lock on a .pack file the exact moment I pressed the "transfer ownership" button.

In the light of the new information, I've found out that my claim that "the transfer repo doesn't access the repo files" was .... incomplete. It turns out that as part of Macaron routing, two functions are executed right before routers/repo/setting.go:SettingsPost() (i.e. before processing the transfer request):

RepoAssignment() performs a lot of queries, all of them to repository refs.
RepoRefByType() calls GetBranchCommit() and GetCommitsCount(); they both open the repository objects to do their work.

If someone is interested, these are the system calls captured by Process Monitor (I still can't reproduce the bug locally):
RepoAssignment.txt
RepoRefByType.txt

That or the code indexing operation I think. But it is always happens. I haven't checked whether I can do it via the API, perhaps it would work then.

I thought about that, but indexing is only performed after actual changes (i.e. commits, import repos). For what you guys said, I think indexing shuold be long complete at the time of your tests. Transferring the ownership doesn't change the repo ID in the database, so the index doesn't need to be updated (and it doesn't).

In my case I verified with pshandle and Process Monitor no open handles were at the directory or any file below it. Still, I thought it might be relevant 👍

In my case I verified with pshandle and Process Monitor no open handles were at the directory or any file below it. Still, I thought it might be relevant 👍

@Sebazzz And it still failed?

Yes, transferring the repository failed. As you mentioned, some actions involving reading the repository happen when clicking the button. Then it failed when moving.

@zeripath Rather than doing very complicate maneuvers to perform a task that works 99% of the time very efficiently, what about this plan?:

Attempt to rename the directory. Success? Done
Call runtime.GC() and back off a couple of seconds.
Retry (maybe a couple of times).

@nikybiasion was successful by "brutally" inserting a 30s pause before the rename.
Maybe only for Windows?

I could live with that, it is not like I make a habit of moving repositories around. If it takes 30 seconds longer it is at least a temporary fix.

I could live with that, it is not like I make a habit of moving repositories around. If it takes 30 seconds longer it is at least a temporary fix.

I don't mean implement a 30 second delay! 😆 Just one and try again. It's only that this has been tested with 30s.

I'm hitting this when renaming a repo in an org:
2019/11/07 15:18:24 ...ters/repo/setting.go:82:SettingsPost() [E] ChangeRepositoryName: rename repository directory: rename D:\Gitea\data\repositories\xxx\aaaaaaa.git D:\Gitea\data\repositories\xxx\yyyy.git: Access is denied.

This might be related.

@Sebazzz I totally think it's related, but I was never able to reproduce. Are you able to reproduce this with a new repo? (e.g. one that has no traffic or a complex history).

Yes, I can reproduce the ownership transfer issue and rename issue on a new repository with only 1 commit.

@guillep2k Yes, I can reproduce the ownership transfer issue and rename issue on a new repository with only 1 commit.
Can I workaround by moving / renaming the directory manually and renaming references in the database?

@Sebazzz Yes, just for a rename you can; for a transfer it's more complicated because of the team permissions; I'm not sure about the correct procedure. If you're pressed to transfer the repo and you don't care about issues/PRs, you could just import/migrate it into the org and delete it from the user's. You need to enable local file migration in app.ini for that.
However, I'm more interested in finding the root cause.  😁
Can you collect the following information for me about the repo and its folder?

In what kind of file-system is the repo based? NTFS? Network?
Can you check the user permissions in the folder (I don't expect surprises here, since it's a lock problem but...)
Can you check the exact path for the Gitea executable is the same as it shows in the .ssh/authorize_keys for its user? (or you can just rewrite the authorized_keys from the admin panel an try the rename/transfer again). Is is possible that you have more than one gitea.exe somewhere in your system?
Does the repo have any non-default git hooks on the server side?

Thank you!

Maybe indexer or other task are running.

@lunny No, I can rename from Windows Explorer or PowerShell just fine.

Can you collect the following information for me about the repo and its folder?
* In what kind of file-system is the repo based? NTFS? Network?

Standard NTFS:
C:\Windows\system32>fsutil fsinfo ntfsinfo D:
NTFS Volume Serial Number :        0x1ed49713d496ec71
NTFS Version   :                   3.1
LFS Version    :                   2.0
Number Sectors :                   0x000000001ffbefff
Total Clusters :                   0x0000000003ff7dff
Free Clusters  :                   0x0000000002f5f140
Total Reserved :                   0x000000000000138f
Bytes Per Sector  :                512
Bytes Per Physical Sector :        4096
Bytes Per Cluster :                4096
Bytes Per FileRecord Segment    :  1024
Clusters Per FileRecord Segment :  0
Mft Valid Data Length :            0x000000006bec0000
Mft Start Lcn  :                   0x00000000000c0000
Mft2 Start Lcn :                   0x0000000000000002
Mft Zone Start :                   0x0000000002d45ea0
Mft Zone End   :                   0x0000000002d526c0
Max Device Trim Extent Count :     4096
Max Device Trim Byte Count :       0xffffffff
Max Volume Trim Extent Count :     62
Max Volume Trim Byte Count :       0x40000000
Resource Manager Identifier :     5094AFF7-A211-11E8-9661-00155D00A402

* Can you check the user permissions in the folder (I don't expect surprises here, since it's a lock problem but...)

Those are fine, I ran an extra recursion to be sure. The gitea user is owner as well.

* Can you check the exact path for the Gitea executable is the same as it shows in the .ssh/authorize_keys for its user? (or you can just rewrite the authorized_keys from the admin panel an try the rename/transfer again). Is is possible that you have more than one gitea.exe somewhere in your system?

"C:\Users[service account].ssh\authorized_keys" is an empty file (I assume you are looking for that file). I actually have SSH disabled.
I ran a dir /b/s gitea.exe in both partitions, there is only one gitea.exe

* Does the repo have any non-default git hooks on the server side?

No, just the default gitea installed hooks.

Thank you!

Thank you 😊

This is the failing operation:
High Resolution Date & Time:	8-11-2019 20:14:24,6529769
Event Class:	File System
Operation:	IRP_MJ_SET_INFORMATION
Result:	ACCESS DENIED
Path:	D:\Gitea\data\repositories\[myuser]\test.git
TID:	6048
Duration:	0.0000187
Type:	SetRenameInformationFile
ReplaceIfExists:	True
FileName:	D:\Gitea\data\repositories\[myuser]\test2.git

After the operation has failed I still can rename the dir from cmd/explorer, so I don't think any handles keep open.
However, based on this issue it appears Windows does not like it when a rename occurs while a handle is still open.

However, based on this issue it appears Windows does not like it when a rename occurs while a handle is still open.

Thank you for all this useful information. Yes, a lock on the directory due to dangling open handles is the main suspect; it's also a noticeable difference in how Windows handles the file systems compared with Linux.
I'll try my best again to reproduce this problem with this information in mind.

I'll try my best again to reproduce this problem with this information in mind.

Good luck, I have done several attempts just now and I can't put my finger on it.
I have tried:

Same server, same partition, same gitea version (1.9.5), indexer enabled;
Almost the same config, even use mssql like the prod instance does;
I migrated (using built-in migrate option) a repo from the prod instance;
It does not matter whether gitea runs as a Windows service or interactively;
Running as administrator or different account does not matter.

I still cannot reproduce it, while it still goes wrong on the prod instance.
I'm not familiar with golang but I will try using delve to debug it perhaps.

This sounds incredibly frustrating! @guillep2k you know it could be TestPullRequests... pr.testPatch doesn't create a temporary repo just a clean index.
If transfer ownership doesn't do:
https://github.com/go-gitea/gitea/blob/c15d371939330f3b7d0e0aeaca3116a7b1c15065/models/pull.go#L609-L610
Then it wouldn't know that the repo is supposed to be locked.
(Because of the way transfer ownership is written we probably need to add all of those locks back in everywhere.)

Somehow a handle to a pack file is kept open:
D:\Gitea\data\repositories\[user]\test.git\objects\pack\pack-e832c7bb532f38e9fbb4214dee7f14b9925789f5.pack

I observed it two times: one time one handle was kept open, one time three handles were kept open. It is not os.Rename after all. If I break the handle, the process goes fine although the second time managed to crash the gitea process.

I got a testcase, somehow. I'm not sure why but it always reproduces.
This is a complete testcase, in my case I ran it at Z:\Dev\Gitea but the paths shouldn't matter.
Download link: https://1drv.ms/u/s!AuWWgEGGFWmIpOEXxslyffIglnw_6w?e=C9OKTQ
Username: testuser
Password: testcase

This is the function that leaks handles:
> code.gitea.io/gitea/modules/context.RepoRefByType.func1() go\src\code.gitea.io\gitea\modules\context\repo.go:565 (hits goroutine(735):4 total:6) (PC: 0x12114b2)
Warning: debugging optimized function
   560: }
   561:
   562: // RepoRefByType handles repository reference name for a specific type
   563: // of repository reference
   564: func RepoRefByType(refType RepoRefType) macaron.Handler {
=> 565:         return func(ctx *Context) {
   566:                 // Empty repository does not have reference information.
   567:                 if ctx.Repo.Repository.IsEmpty {
   568:                         return
   569:                 }
   570:

In this function the leaking handle is created.

Aha.
 It is the only large change in this codepath. RepoRefByType hasn't changed in the last two years except for a name change. In addition, 1.8.3 is the last known version to be working and 1.9.0 is the first version to include #6478 which is essentially using a different library to read the repositories if I read the pull request correctly.

@Sebazzz #6478 is almost certainly the cause.

@zeripath ctx.Repo.GitRepo, err = git.OpenRepository(repoPath) . There is no Close for the repository.

@zeripath ctx.Repo.GitRepo, err = git.OpenRepository(repoPath) . There is no Close for the repository.

No but there is in storage.dir. That holds the descriptors/handles for the opened packfiles. It should, at least for Windows, be closed prior to rename/TransferOwnership or have KeepDescriptors set to false. I don't know whether you want to keep this leak for Linux.

@lunny @zeripath I think we should destroy ctx.Repo.Repository before the rename/migration, as it will be invalid afterwards anyway. We may need to explicitly call gc after that. At least as a workaround. In the meantime, we could ask for a Close() method upstream perhaps?

@guillep2k Just like what @Sebazzz said. It has Close on Storage, but we haven't hold it on Repository. And we storage := filesystem.NewStorageWithOptions(fs, cache.NewObjectLRUDefault(), filesystem.Options{KeepDescriptors: true}) use KeepDescriptors.
@filipnavara Have you remember why use KeepDescriptors as true here? Could you change it to false simply?

OK, filesystem.Storage has ObjectStorage as a field which does have a Close method.
We set this as a private field in git.Repository here:
https://github.com/go-gitea/gitea/blob/a647a54a08fc78286ea6ded008ea368f43e7c2ca/modules/git/repo.go#L111
So we could add a Close() method to git.Repository

Do you remember why use KeepDescriptors as true here? Could we change it to false simply?

It is performance optimization to avoid constant re-opening of the file [for the duration of one page load]. As @zeripath pointed out there's a Close method that should be called at some point. It probably got lost during one of my rebases when adjusting the code.

Is that Close method also worth calling at the end of every request instead of relying on the GC in general (beside the solution of calling it early for these two bugs)?


Gh-2722: Improve code analysis

Related Issue

Resolve #2722

Codecov Report

:exclamation: No coverage uploaded for pull request base (v2-alpha@8a74c1a). Click here to learn what that means.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             v2-alpha    #2871   +/-   ##
===========================================
  Coverage            ?   69.46%
  Complexity          ?      494
===========================================
  Files               ?       79
  Lines               ?     1513
  Branches            ?      114
===========================================
  Hits                ?     1051
  Misses              ?      380
  Partials            ?       82

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


getCredentialsForIdentity returns incorrect expiration

Describe the bug
When calling getCredentialsForIdentity the expiration is not returned properly by the SDK. The expiration when converted to epochSeconds returns 1 which is year 1970.
Expected behavior
Client should return expiration that points to current timestamp.
Current behavior
Expiration points to year 1970 and epochSeconds is 1.
Steps to Reproduce
Call cognitoIdentityClient.getCredentialsForIdentity.
Possible Solution
The conversion to Instant should multiply expiration by 1000 before converting to Instant to get correct timestamp.
Context
No response
AWS Kotlin SDK version used
0.16.3-beta
Platform (JVM/JS/Native)
Native
Operating System and version
Android 10

Cognito's raw API response includes expiration seconds in scientific notation, such as 1.659377625E9. Our current parser only searches for digits and the decimal dot and ignores anything after the E, thus reading a number smaller than 10.

OK, I've verified a change that allows a getCredentialsForIdentity call to return a correct expiration value. The change is reviewed and pushed to main. It should be present in this week's release.


feat/autocomplete recipient

closes: #3102
Additionally
fixes condition where multisig address delete icon is visible
adds a more prominent shadow to the Truncated text component

I suggest to squash commits into one feature.


Subject Name ambiguous

"The device certificate (also called a leaf certificate) must have the Subject Name set to the Device ID that was used when registering the IoT device in the Azure IoT Hub. This setting is required for authentication."
^ In the above passage, does the Subject Name refer to the "CN" or "common name" field of a Subject in an x.509 certificate, or the entire Subject?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3eedf7b5-8398-42dd-2d6c-d0180f90c4c8
Version Independent ID: 86969fbb-3b98-296c-32b9-068b30470dcf
Content: Overview of Azure IoT Hub X.509 CA security
Content Source: articles/iot-hub/iot-hub-x509ca-overview.md
Service: iot-hub
GitHub Login: @eustacea
Microsoft Alias: eustacea

@toddgauntgs Thanks for the feedback! I have assigned the issue to the content author to help respond, evaluate and update as appropriate.

Hello,
This refers to the "CN" name field.
Thanks,
Eustace

@toddgauntgs Was the previous comment useful?

@Alberto-Vega-MSFT I had already figured this out after some testing a while back, though good to have this documented clearly. Thanks for following up.

Hi @toddgauntgs,
Thanks very much for your feedback. I've updated the sentence to specifically call out the use of the CN attribute. I'm going to go ahead and close this issue. Please @ comment me here if you think we need to address this further.
Thanks again for bringing this to our attention!
-Jimaco

#please-close


Use lowest retryAfter when no backends are available

We keep track of the LastRetryAfter value in load_balanced.py. When no backends are available, and the last attempted backend possibly has a high retryAfter value, we would wait more than we need to as other backends may have become available again.
What I believe we should do then is return the nearest upcoming retry_after datetime property in the backends collection. The spec allows for either a datetime or seconds. I expect the httpx client to honor both.

Fixed


Changed package.json to remove deployment error

Fixes issue #22
Changes:
changed package.json and updated it's dependancies It's now building and running.

@AliAyub007 Thanks.
Please also engage other developers to review your PRs in all your commits.


Converted the print calls in the backend package initialization into Python logging calls

Summary
This pull request moves from printing on stderr the "Using X backend" message to sending it to the Python logging module in the backend package __init__.py file.
The log level for these messages has been set to "debug" as if everything works as expected there is no need to inform about which backend is used. On the other hand, I understand that maintainers might want to elevate this specific message to an "info".
Related Issues
#1406
#11332
PR Overview

[n] This PR requires new unit tests [y/n] (make sure tests are included)
[y] This PR requires to update the documentation [y/n] (make sure the docs are up-to-date)
[y] This PR is backwards compatible [y/n]
[n] This PR changes the current API [y/n] (all API changes need to be approved by fchollet)

Closed as the documentation was not correctly updated to reflect the changes


Can not search.

Hi, I get a problem, When I call the select2 component in bootstrap modal. The input element can not foucs or type. I think it's a bug. example

This is a duplicate of https://github.com/select2/select2/issues/600#issuecomment-102857595.


HTTP/2 GOAWAY logic doesn't support graceful shutdown

From section 6.8:

A server that is attempting to gracefully shut down a
connection SHOULD send an initial GOAWAY frame with the last stream
identifier set to 2^31-1 and a NO_ERROR code.  This signals to the
client that a shutdown is imminent and that no further requests can
be initiated.  After waiting at least one round trip time, the server
can send another GOAWAY frame with an updated last stream identifier.
This ensures that a connection can be cleanly shut down without
losing requests.

We need to support sending 2 GOAWAY frames in the case of graceful shutdown.

@buchgr's PR https://github.com/netty/netty/pull/3516 will handle this I think.

@Scottmitch yes. It will allow sending multiple GOAWAY frames as long as the last stream identifier is less than the last stream identifier of the previous GOAWAY frame. So this should work.

Closing PR https://github.com/netty/netty/pull/3516 has been cherry-picked.

Hi @buchgr @nmittler @Scottmitch,
I know the issue is closed, But have one doubt regarding section 6.8:
Is it mandatory server (here netty) to send multiple GOAWAYs always ?
 A client that is unable to retry requests loses all requests that are
   in flight when the server closes the connection.  This is especially
   true for intermediaries that might not be serving clients using
   HTTP/2. A server that is attempting to gracefully shut down a
connection SHOULD send an initial GOAWAY frame with the last stream
identifier set to 2^31-1 and a NO_ERROR code. This signals to the
client that a shutdown is imminent and that no further requests can
be initiated. After waiting at least one round trip time, the server
can send another GOAWAY frame with an updated last stream identifier.
This ensures that a connection can be cleanly shut down without
losing requests.

From the above statement, it says two GOAWAYs should be sent.
I am asking this as of today when Netty is gracefully shutting down. it sends the first GOAWAY  with lastStreamId as the lastStreamId known to the server and then waits for the request to process and then closes the connection.
is this the right behavior?
Below is the pcap that I captured when sending a request to the spring cloud gateway which is using the Netty server. and request delay is 8 seconds


is_*_dtype functions don't accept extension dtypes

The _ArrayOrDtype alias doesn't include ExtensionDtype, which I believe all the is_*_dtype functions accept.

Thanks for the report.  Simple fix is to add ExtensionDtype here:
https://github.com/pandas-dev/pandas-stubs/blob/db3b883dbe8d22863c8aca37c89431afce3b57e2/pandas-stubs/core/dtypes/common.pyi#L32
Should add tests for various types like str, "str", ExtensionDtype, etc. to the tests in https://github.com/pandas-dev/pandas-stubs/blob/main/tests/test_api_types.py

Should add tests for various types like str, "str", ExtensionDtype, etc. to the tests in https://github.com/pandas-dev/pandas-stubs/blob/main/tests/test_api_types.py

I think we had test for ExtensionDtype in this file.

I think we had test for ExtensionDtype in this file.

Yes, but not for the is_*_dtype functions.

Yes, but not for the is_*_dtype functions.

Ya, i'll add them.

Sir, do you have a short example for ExtensionDtype i am unable to get one

Sir, do you have a short example for ExtensionDtype i am unable to get one

You just want to make sure that things like is_bool_dtype(ExtensionDtype) work  (and similar for the other is_*_dtype() functions.
Also want to add tests for native types and their string representations.

ExtensionDtype is a custom data-type but many is_*_dtype() functions in pytest are saying that they cannot interpret it as data-type

ExtensionDtype is a custom data-type but many is_*_dtype() functions in pytest are saying that they cannot interpret it as data-type

Write an example that fails and show it, and I can look into it

    check(assert_type(api.is_object_dtype(ExtensionDtype), bool), bool)

this returns
FAILED tests/test_api_types.py::test_is_object_dtype - TypeError: Cannot interpret '<property object at 0x7fc56b581fd0>' as a data...

I think that's a bug in is_object_dtype() that I'll have to report.  So leave out that test for now there.

Actually 11 of the are failing which are
is_complex_dtype
is_datetime64_any_dtype
is_datetime64_dtype
is_float_dtype
is_int64_dtype
is_integer_dtype
is_numeric_dtype
is_object_dtype
is_signed_integer_dtype
is_timedelta64_dtype
is_unsigned_integer_dtype

Thanks.  I created https://github.com/pandas-dev/pandas/issues/50923 to report this.
Can you still include them in the tests, but comment them out.  E.g.
# check(assert_type(api.is_object_dtype(ExtensionDtype), bool), bool)   pandas GH 50923

Then whenever that gets fixed, we can put back the tests in the future.

Thanks. I created pandas-dev/pandas#50923 to report this.
Can you still include them in the tests, but comment them out. E.g.
# check(assert_type(api.is_object_dtype(ExtensionDtype), bool), bool)   pandas GH 50923

Then whenever that gets fixed, we can put back the tests in the future.

Yes i'll do that


Add js library to the libaries project

(Feature) Add js library to the library set
Currently, the project only contains go and python implementation of the support library. Since Bassa project mainly involves js and it is getting more popular to use js with web development, it would be potential improvement if we add js library to the library set.
Current Behavior
Current library set does not contain library with js implementation
Possible Solution
Implement the main required function in js
Context
NA
Your Environment
NA

https://github.com/c2siorg/bassa-client-libraries/issues/1#issuecomment-1959323234
Please feel free to work on it.


Solves the problem with starting productions with websocket-sources

Disabled if no production configuration is set:

When production configuration is set (e.g. LD + HQ Pipeline):

Production with HTML and Media Player sources:

Multiviewer example, with example HTML URL loaded and Media player placeholder:


Add PostgreSql database support

Why you need it?
Is your feature request related to a problem? Please describe in details
#1170 #1091
How it could be?
A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.
I will support this feature.
Other related information
Add any other context or screenshots about the feature request here.

@l81893521 this feature development is assigned to you, thank you for your contribution.


[6.0][Diagnostics] Stop using unicode line characters

Cherry-pick #2581 into release/6.0
CCC info incoming

https://github.com/apple/swift/pull/72806
@swift-ci Please test


Make library match what's in the template

To start with, I think it would be good to have an MVP which just lets people add library and remove code from their api tests, see if that's useful and get feedback before changing anything. Though I have some questions about how HttpClient trait is meant to be used by teams and it would be good to see some github search results showing how stuff is used to check if people will be able to move or if they have customised stuff a lot.

superseded by other changes


Documentation for TileDB

Hello there,
I notice TileDB is one of the inputs to the cirrocumulus app on the documentation site, I was wondering if there's any specific restrictions on the structure and a preferred way of converting datasets from h5ad to tiledb ?
Thank you!

The TileDB format is currently only compatible with the format used by cellxgene


Made IE11 scrollbar check more precise (updated) (fixes #621)

Updated #625 to match current master.
This is just the fix in the source code. To ensure effortless merging, I didn't rebuild the assets here.

This has been superseded by https://github.com/jshjohnson/Choices/pull/740 :) thanks


Remove Cocoapods from iOS installation guide.

As mentioned in #67, Cocoapods is not supported at this time.

It seems that CI test failure is not caused by code change. How to re-run tests?
The command "sudo apt-get install clang git libssl-dev" failed and exited with 100 during .

Sounds good, I'll merge, thanks for your contribution @jianjunz


Streams property renamed

CI passed: https://github.com/intel-innersource/frameworks.ai.openvino.ci.product-configs/pull/884


Put planner with threadpool/pulse dependencies behind feature

My own use case has found that the sequencing of components is essentially linear

(a quiet user of specs dropping my two cents)
Sorry if I'm jumping the gun a bit on this; I know this PR just feature-gates the planner, but I wanted to get ahead of this change. I actually do use the planner, but I don't use it raw -- I've written a wrapper that automatically identifies the system priorities from explicit dependency annotations.

In use
A sample annotation in a system
Test demoing simple usage

My janky wrapper isn't exactly ready for anyone to look at let alone incorporate into specs, but I wanted to emphasize that at least one person uses the planner and that it might not be great to hide this feature.
It seems that the planner in its current state is "too much" for linear hierarchies, but "too little" for complex non-linear hierarchies. Maybe we could use this discussion point to spurn more discussion about what the planner is supposed to do for the consumer?

NB I've made the planner a default feature; it's opt-out, not opt-in

@serprex The weakness here isn't in Planner or the problem domain. It's in your analysis. Two systems can run at the same time if all shared components are accessed as read-only. If you break up your larger systems into smaller stages, you'll expose many more places throughout your code where this can happen. Some things you might try:

Instead of a giant enum (AiState::Random, AiState::Player...) use separate components entirely (struct AiStateRandom, struct AiStatePlayer...). Write separate systems to handle each, and another system that executes AI state changes at the end of a turn when other stuff is happening.
Use short-lived components for intermediate calculations. For example, if two different systems need to know the position of an entity's foe, create a lightweight AiFoePosition component and write a third system that does nothing but insert and delete it.
Perform calculations early, and discard them later for entities that don't need them. For example, you might have an AiRandomDirection component that gets inserted on every frame for every single entity, but only used in the DoAiRandom system.

If this level of granularity seems like overkill for your game, you might not need ECS in the first place. That's fine, of course.

(using stack-based responding)
@malleusinferni Thanks for a detailed answer!
@acmcarther looks interesting! My worry would be the redundancy of dependency information - first you declare it with your new annotation, but then you still implicitly depend on other systems by sharing the components. So we'd need to take measures to ensure these two dependency trackers are synced, and that would involve some complexity.

My own use case has found that the sequencing of components is essentially linear

Current parallelization of tasks is far from optimal, sometimes producing sequential execution, but this is an implementation detail ought to change. For example, the most recent discussions about the ticketed locks (@amaranth) would allow further lookup for systems able to run in parallel, improving the efficiency.

The idea to make planner optional though has been on the table for a while, and I'm glad to see it being requested here (with a nice PR!). @csherratt could you have a look?

LGTM


has.watcher( function or ref )

Should install set hook, calling function( value ) lazily resolving reference to the function.
Useful for communication with parent react components.

fixed in feature branch


[Docs] Examples of of OAM endpoints

@utkarsh-pro thanks for clarifying. Examples of endpoints are ideal; a set of examples that provide something of a template such that a contributor could plugin the name of an object (by taking a guess) and hit the endpoint even though not all endpoints are exhaustively listed in the docs.
Originally posted by @leecalcote in https://github.com/meshery/meshery/pull/4943#discussion_r786280208

@utkarsh-pro little help here, please.

@leecalcote on it...


Support escaping mustaches in templates

This fixes #276, which was closed as wontfix. Our docs currently use handlebars, which supports escaping mustaches with '', so this does the same for Ractive.
Feel free to close this one wontfix too. I just needed a brief distraction to clear my head, and none of the current open issues aligned with my mood correctly.

I ran into this exact problem putting a presentation together the other day, I think this makes sense


fix: link fuel-ui broken; start support for dynamic deps linking

rename dev:with-links to dev:deps-link
create script deps.sh

dependencies now are defined in deps variable
links dependencies
runs dev server with local links on
this removes the need to use regex in vite.base.config, as we know exactly the name of deps, just need to iterate them
this allow us to include different dependencies (as long as follow same build pattern resolve file)

Update docs with new info

Note
This PR is not meant to completely support dynamic linking of dependencies. This PR is mainly a fix, with a refactor aiming to start a support for dynamic links.
For that we need to work further, mainly because of not all libs will have output build file as /dist/index.mjs . I think we can continue this work later in other PR as it's not the priority now and we got fuel-ui link working, which is main objective now.

The regex for matching only fuel-ui/* packages should look something like this:
alias: [{
  find: /(@fuel-ui\/[^\s]+)/,
  replacement: path.resolve(__dirname, '../node_modules/$1/dist/index.mjs'
}],

Live demo/playground:

https://regexr.com/77cf3

The regex for matching only fuel-ui/* packages should look something like this:
alias: [{
  find: /(@fuel-ui\/[^\s]+)/,
  replacement: path.resolve(__dirname, '../node_modules/$1/dist/index.mjs'
}],

Live demo/playground:

https://regexr.com/77cf3

THIS PR removes the need to use regex in vite.base.config, as we know exactly the name of deps, just need to iterate over them

IMO, regexes are ideal for string match/replace, providing a smaller code footprint. I am fond of it. :)
Would you mind sharing why you prefer manually iterating over pre-configured environment variables?

IMO, regexes are ideal for string match/replace, providing a smaller code footprint. I am fond of it. :)
Would you mind sharing why you prefer manually iterating over pre-configured environment variables?

Yes I agree regex are ideal for that, but for this use case match/replace is not needed.
we want to make sure we only apply aliases for dependencies that are being linked locally.
With regex we open room to find other libs, and even if we build a more strict regex, we don't really need to find anything in string, we just need to build a path with the exact dependency name the user provided
for example:
Let's say I have 4 libs:

@fuel-ui/css
@fuel-ui/react
@fuel-ui/test-utils
@fuel-ui/config

If I only want to link @fuel-ui/react, it should be possible

One last example of a strict and flexible regex:

/(@fuel-ui\/(react|css|config|test-utils))/ (demo)

It could have many variations:

/(@fuel-ui\/(react))/
/(@fuel-ui\/(react|css))/
/(@fuel-ui\/(react|css|config))/
/(@fuel-ui\/(react|css|config|test-utils))/
/(@fuel-ui\/(react|css|config|test-utils|new-lib-from-the-future))/

Even these seem more concise than a mix of env vars and manual iteration.
Feel free to use the approach you think is best.
Over and out. 🫡

@arboleya I added support to fuel-ts as well now
the dependencies come into node front-end process in LINK_DEPS env var, because we reuse them from prev command executed in deps.sh
if we want a regex to process it, would need to build it dynamically, which can be tricky because of characters inside dependency name that would need to be escaped (@ /  white space, others?)


Buggy Components page.

http://www.getmdl.io/components/index.html
Components page itself is not good example how to code front-end.
Its code returns a lot of validation errors with something as obvious as this one:
A document must not include more than one main element.

What exactly is causing usability issues?
Pure HTML validation isn't necessarily a guideline for what is a problem. Having specific issues and the problems they cause would help here.


support check block for tf 1.5.0+

As of Terraform 1.5, support has been added for check blocks.
https://github.com/hashicorp/terraform/blob/v1.5/CHANGELOG.md#150-june-12-2023
https://developer.hashicorp.com/terraform/language/checks
I'm adding check type support in a form similar to import block.

@simar7 Thank you for merge! I'm hoping for an early release, as tfsec currently gives me an error with tf 1.5.0+

Yes, releases for Trivy and defsec take place end of each month.


Unable to add image using anchore cli which is hosted on azure container registry

Is this a request for help?: Yes

Is this a BUG REPORT or a FEATURE REQUEST? (choose one): BUG REPORT
Steps to Install Anchore suite
Created Postgres PAAS on Azure
Configured Postgres DB on config yamls
Installed anchore core engine and analyzer as pods on k8s cluster.
 I'd like to close this issue as a duplicate of 18, so please add a comment in that ticket that you too are impacted so we only have to track in one issue. Given that this is impacting more folks, we'll see what kind of workaround we can do regarding a custom skopeo build and will update that ticket with info. Thanks!

The latest release of Skopeo now has Azure support, so if you want to pull the latest version into a custom container based on the anchore/anchore-engine:v0.2.1 container that should be a sufficient workaround to get Azure support until we release the next engine version container with the updated tool in it.

Anchore engine version 0.2.2 includes skopeo version 0.1.29, which should resolve this incompatibility!


How to override unfold's login page with django-allauth's.

          @justinqian42 please create a separate ticket related to django-allauth and I will take a look.

Originally posted by @lukasvinclav in https://github.com/unfoldadmin/django-unfold/issues/754#issuecomment-2363364867
This isn't an issue, but trying to give those who have the same requirement a hint.
What:
Integration between django-unfold and django-allauth. Overriding the unfold's login page with allauth's, so that users will be redirected to it.
How:
Allauth actually provides a handy decorator. Ref: https://docs.allauth.org/en/latest/common/admin.html
The only thing you need to do is --
add
admin.autodiscover()
admin.site.login = secure_admin_login(admin.site.login)

before
urlpatterns = [ ... ]

The reason why I'm not decorating an UnfoldAdminSite instance is that the allauth decorator is designed for the original one. The allauth decorator and templates don't honour the unfold's "image" or "redirect_after" parameters anyway, so it makes no difference.
Through this way, we could benefit from allauth's features, like rate-limiting and third party login methods.
However, the default allauth login page lacks the unfold's styling.

Okay, so I checked the docs and read your comment multiple times. Where exactly is the problem and what is your error message?

No this isn’t an issue.
Just wanted to share another way of applying django-allauth apart from the method in #759 .
It can be closed.


When text is input in a text field, hint text should not be announced in talkback mode

Internal bug: b/264211793.
This issue is copied from the above bug, filed by customer: money.
Steps to Reproduce
Hint text is announced with no input:

Hint text is announced with input:

Expected results:
When text is input in a text field, hint text is not expected to be announced in talk back mode.
Actual results:
Hint text is announced in talk back mode

Code sample
Scaffold(
  appBar: AppBar(title: Text('Flutter Demo Home Page')),
  body: TextField(
    decoration: InputDecoration(hintText: 'Send a message...'),
  ),
)

Related issue: https://github.com/flutter/flutter/issues/114511
We already excluded hint text semantics when text field has input and label text is provided. The reason we didn't exclude the hint text when text field has input and no label text is provided is that we think the hint text is likely the label.
@goderbauer Do you think we should exclude the hint text semantics when there is an input no matter if there is a label text or not?

FWIW I would recommend not trying to "do the right thing" in order to handle broken apps, just do the technically correct thing and let apps fail. Otherwise, what happens is that people start depending on the heuristics and then you quickly get to a place where the real API is the heuristics and they are hard to explain, hard to debug, and hard to use.