Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start page: "slow" response time #21031

Closed
somera opened this issue Sep 2, 2022 · 33 comments · Fixed by #21033
Closed

Start page: "slow" response time #21031

somera opened this issue Sep 2, 2022 · 33 comments · Fixed by #21033
Labels

Comments

@somera
Copy link

somera commented Sep 2, 2022

Description

This is not a bug. But I try to understand what gitea is doing.

I'm using my gitea for mirror external projects. Means, I have a lot of data. Now I see, that the start page need ~1 second for the first response. Gitea is running in local network.

If I open the gitea start page for user with only one project I see this:

image

And this result

image

is for user with a lot of projects.

This is the log for the longer run:

2022/09/02 16:59:14 models/user/user.go:996:GetUserByIDCtx() [I] [63121a42] [SQL] SELECT "id", "lower_name", "name", "full_name", "email", "keep_email_private", "email_notifications_preference", "passwd", "passwd_hash_algo", "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", "is_restricted", "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", "repo_admin_change_team_access", "diff_view_style", "theme", "keep_activity_private" FROM "user" WHERE "id"=$1 LIMIT 1 [1] - 1.754489ms
2022/09/02 16:59:14 .../issues/stopwatch.go:132:HasUserStopwatch() [I] [63121a42] [SQL] SELECT "id", "issue_id", "user_id", "created_unix" FROM "stopwatch" WHERE (user_id = $1) LIMIT 1 [1] - 831.954µs
2022/09/02 16:59:14 models/org.go:71:GetUserOrgsList() [I] [63121a42] [SQL] SELECT "user".id,"user".name,"user".full_name,"user".visibility,"user".avatar,"user".avatar_email,"user".use_custom_avatar, count(distinct repo_id) as org_count FROM "user" INNER JOIN "team" ON "team".org_id = "user".id INNER JOIN "team_user" ON "team".id = "team_user".team_id LEFT JOIN (SELECT id as repo_id, owner_id as repo_owner_id FROM repository WHERE ("repository".is_private=$1 AND "repository".owner_id NOT IN (SELECT id FROM "user" WHERE type=$2 AND visibility IN ($3))) OR "repository".id IN (SELECT repo_id FROM "access" WHERE "access".user_id=$4 AND "access".mode>$5) OR "repository".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=$6) OR "repository".owner_id=$7 OR ("repository".is_private=$8 AND "repository".owner_id IN (SELECT "org_user".org_id FROM org_user WHERE "org_user".uid=$9))) "repository" ON "repository".repo_owner_id = "team".org_id WHERE ("team_user".uid = $10) GROUP BY "user".id,"user".name,"user".full_name,"user".visibility,"user".avatar,"user".avatar_email,"user".use_custom_avatar ORDER BY "user"."name" ASC [false 1 private 1 0 1 1 false 1 1] - 56.467784ms
2022/09/02 16:59:14 ...ers/web/user/home.go:79:Dashboard() [I] [63121a42] [SQL] SELECT count(*) FROM "org_user" WHERE (uid=$1) [1] - 1.239558ms
2022/09/02 16:59:14 ...dels/user_heatmap.go:71:getUserHeatmapData() [I] [63121a42] [SQL] SELECT created_unix / 900 * 900 AS timestamp, count(user_id) as contributions FROM "action" WHERE user_id=$1 AND act_user_id=$2 AND (created_unix > $3) GROUP BY timestamp ORDER BY timestamp [1 1 1630594754] - 1.663216ms
2022/09/02 16:59:14 ...odels/repo/mirror.go:174:GetUserMirrorRepositories() [I] [63121a42] [SQL] SELECT "id", "owner_id", "owner_name", "lower_name", "name", "description", "website", "original_service_type", "original_url", "default_branch", "num_watches", "num_stars", "num_forks", "num_issues", "num_closed_issues", "num_pulls", "num_closed_pulls", "num_milestones", "num_closed_milestones", "num_projects", "num_closed_projects", "is_private", "is_empty", "is_archived", "is_mirror", "status", "is_fork", "fork_id", "is_template", "template_id", "size", "is_fsck_enabled", "close_issues_via_commit_in_any_branch", "topics", "trust_model", "avatar", "created_unix", "updated_unix" FROM "repository" WHERE (owner_id = $1) AND (is_mirror = $2) [1 true] - 721.573µs
2022/09/02 16:59:14 ...odels/repo/mirror.go:146:loadAttributes() [I] [63121a42] [SQL] SELECT "id", "repo_id", "interval", "enable_prune", "updated_unix", "next_update_unix", "lfs_enabled", "lfs_endpoint" FROM "mirror" WHERE (id > 0) AND "repo_id" IN ($1,$2) [13734 13735] - 463.139µs
2022/09/02 16:59:15 models/action.go:364:GetFeeds() [I] [63121a42] [SQL] SELECT "action".* FROM "action" INNER JOIN "repository" ON "repository".id = "action".repo_id WHERE user_id=$1 AND is_deleted=$2 ORDER BY "action"."created_unix" DESC LIMIT 20 [1 false] - 586.989343ms
2022/09/02 16:59:15 ...odels/action_list.go:39:loadUsers() [I] [63121a42] [SQL] SELECT "id", "lower_name", "name", "full_name", "email", "keep_email_private", "email_notifications_preference", "passwd", "passwd_hash_algo", "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", "is_restricted", "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", "repo_admin_change_team_access", "diff_view_style", "theme", "keep_activity_private" FROM "user" WHERE "id" IN ($1,$2,$3,$4) [2039 2040 2042 156] - 718.559µs

This

2022/09/02 16:59:15 models/action.go:364:GetFeeds() [I] [63121a42] [SQL] SELECT "action".* FROM "action" INNER JOIN "repository" ON "repository".id = "action".repo_id WHERE user_id=$1 AND is_deleted=$2 ORDER BY "action"."created_unix" DESC LIMIT 20 [1 false] - 586.989343ms

query is the trigger for the slowdown. And this https://explain.depesz.com/s/BEHk#html is the plan for the query on my instance.

My questions:

  • Why is gitea exuting this query fot the start page?
  • More data = longer loading time for the gitea startpage?

Gitea Version

1.17.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.25.1

Operating System

Ubuntu 20.04.4

How are you running Gitea?

Self hosted gitea-1.17.1-linux-amd64

Database

PostgreSQL

@somera somera added the type/bug label Sep 2, 2022
@somera
Copy link
Author

somera commented Sep 2, 2022

Answer for the first question: "Why is gitea exuting this query fot the start page?" -> this will be shown on the start page. Last 20 actions.

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

This is strange because it indicates that the indices are not being used correctly. The plan should look like:

                                               QUERY PLAN                                                
---------------------------------------------------------------------------------------------------------
 Limit  (cost=57.14..57.15 rows=5 width=393)
   ->  Sort  (cost=57.14..57.15 rows=5 width=393)
         Sort Key: action.created_unix DESC
         ->  Nested Loop  (cost=0.57..57.08 rows=5 width=393)
               ->  Index Scan using "IDX_action_user_id" on action  (cost=0.29..15.58 rows=5 width=393)
                     Index Cond: (user_id = 18059)
                     Filter: (NOT is_deleted)
               ->  Index Only Scan using repository_pkey on repository  (cost=0.28..8.30 rows=1 width=8)
                     Index Cond: (id = action.repo_id)
(9 rows)

What is the result of \d action on the psql console?

It should look something like:

                                      Table "public.action"
    Column    |          Type          | Collation | Nullable |              Default               
--------------+------------------------+-----------+----------+------------------------------------
 id           | bigint                 |           | not null | nextval('action_id_seq'::regclass)
 user_id      | bigint                 |           |          | 
 op_type      | integer                |           |          | 
 act_user_id  | bigint                 |           |          | 
 repo_id      | bigint                 |           |          | 
 comment_id   | bigint                 |           |          | 
 is_deleted   | boolean                |           | not null | false
 ref_name     | character varying(255) |           |          | 
 is_private   | boolean                |           | not null | false
 content      | text                   |           |          | 
 created_unix | bigint                 |           |          | 
Indexes:
    "action_pkey" PRIMARY KEY, btree (id)
    "IDX_action_act_user_id" btree (act_user_id)
    "IDX_action_au_r_c_u_d" btree (act_user_id, repo_id, created_unix, user_id, is_deleted)
    "IDX_action_comment_id" btree (comment_id)
    "IDX_action_created_unix" btree (created_unix)
    "IDX_action_is_deleted" btree (is_deleted)
    "IDX_action_is_private" btree (is_private)
    "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted)
    "IDX_action_repo_id" btree (repo_id)
    "IDX_action_user_id" btree (user_id)

@somera
Copy link
Author

somera commented Sep 2, 2022

I'm using this

PostgreSQL 13.8 (Ubuntu 13.8-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit

@somera
Copy link
Author

somera commented Sep 2, 2022

                                          Tabelle »public.action«
    Spalte    |          Typ           | Sortierfolge | NULL erlaubt? |            Vorgabewert
--------------+------------------------+--------------+---------------+------------------------------------
 id           | bigint                 |              | not null      | nextval('action_id_seq'::regclass)
 user_id      | bigint                 |              |               |
 op_type      | integer                |              |               |
 act_user_id  | bigint                 |              |               |
 repo_id      | bigint                 |              |               |
 comment_id   | bigint                 |              |               |
 is_deleted   | boolean                |              | not null      | false
 ref_name     | character varying(255) |              |               |
 is_private   | boolean                |              | not null      | false
 content      | text                   |              |               |
 created_unix | bigint                 |              |               |
Indexe:
    "action_pkey" PRIMARY KEY, btree (id)
    "IDX_action_au_r_c_u_d" btree (act_user_id, repo_id, created_unix, user_id, is_deleted)
    "IDX_action_comment_id" btree (comment_id)
    "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted)

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

Ah... I've just seen that there are some "legacy" indices in my example above. I've just got the same schema as you and found the following query plan:

 tc5=# explain select action.* from action inner join "repository" ON "repository".id = "action".repo_id WHERE user_id=18059 AND is_deleted=false ORDER BY "action"."created_unix" DESC LIMIT 20
;
                                               QUERY PLAN                                                
---------------------------------------------------------------------------------------------------------
 Limit  (cost=1677.66..1677.67 rows=5 width=393)
   ->  Sort  (cost=1677.66..1677.67 rows=5 width=393)
         Sort Key: action.created_unix DESC
         ->  Nested Loop  (cost=0.57..1677.60 rows=5 width=393)
               ->  Index Scan using "IDX_action_r_u_d" on action  (cost=0.29..1636.10 rows=5 width=393)
                     Index Cond: ((user_id = 18059) AND (is_deleted = false))
               ->  Index Only Scan using repository_pkey on repository  (cost=0.28..8.30 rows=1 width=8)
                     Index Cond: (id = action.repo_id)
(8 rows)

EDIT: I'd put up the wrong plan this is the right one

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

Damn I suspect this means that postgres needs different indices to that of MySQL and other DBs and I was led down the garden path by my previous testing with old indices present.

OK I guess we just need to twiddle with the indices until we find the quickest for this.

@somera
Copy link
Author

somera commented Sep 2, 2022

Damn I suspect this means that postgres needs different indices to that of MySQL and other DBs and I was led down the garden path by my previous testing with old indices present.

OK I guess we just need to twiddle with the indices until we find the quickest for this.

Ok. Sounds good.

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

Could you compare which is faster between doing:

CREATE INDEX ON action (user_id, is_deleted)

And:

CREATE INDEX ON action (user_id)

?

@somera
Copy link
Author

somera commented Sep 2, 2022

Not faster.

https://explain.depesz.com/s/6vv0

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

That's very weird because it should be using the index - which your explain does not show. Certainly it works for me.

You will likely need to drop those new indexes before restarting Gitea btw - (I've just discovered that there is a bug in xorm related to its schema reading.)

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

What version of postgres are you running?

@somera
Copy link
Author

somera commented Sep 2, 2022

Added CREATE INDEX ON action (user_id, is_deleted) -> https://explain.depesz.com/s/bqTF

Added CREATE INDEX ON action (user_id) -> https://explain.depesz.com/s/tJisn

Removed CREATE INDEX ON action (user_id, is_deleted) -> https://explain.depesz.com/s/oVKH

@somera
Copy link
Author

somera commented Sep 2, 2022

I'm using this

PostgreSQL 13.8 (Ubuntu 13.8-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit

@zeripath here my PG Version.

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

I just don't understand why it isn't using any of the indices.

I mean this is the plan I get with the user_id and is_deleted index:

;
                                                   QUERY PLAN                                           >
-------------------------------------------------------------------------------------------------------->
 Limit  (cost=61.00..61.02 rows=5 width=393)
   ->  Sort  (cost=61.00..61.02 rows=5 width=393)
         Sort Key: action.created_unix DESC
         ->  Nested Loop  (cost=0.57..60.94 rows=5 width=393)
               ->  Index Scan using action_user_id_is_deleted_idx on action  (cost=0.29..19.44 rows=5 wi>
                     Index Cond: ((user_id = 18059) AND (is_deleted = false))
               ->  Index Only Scan using repository_pkey on repository  (cost=0.28..8.30 rows=1 width=8)
                     Index Cond: (id = action.repo_id)
(8 rows)

It just makes no sense to me that it would not use the index. That's why we have an index. Even the "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted) should have been enough.

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

I mean you could try:

CREATE INDEX ON action (created_unix DESC)

However, I note that even your no ORDER BY query still isn't using an index.

@somera
Copy link
Author

somera commented Sep 2, 2022

I just don't understand why it isn't using any of the indices.

I mean this is the plan I get with the user_id and is_deleted index:

;
                                                   QUERY PLAN                                           >
-------------------------------------------------------------------------------------------------------->
 Limit  (cost=61.00..61.02 rows=5 width=393)
   ->  Sort  (cost=61.00..61.02 rows=5 width=393)
         Sort Key: action.created_unix DESC
         ->  Nested Loop  (cost=0.57..60.94 rows=5 width=393)
               ->  Index Scan using action_user_id_is_deleted_idx on action  (cost=0.29..19.44 rows=5 wi>
                     Index Cond: ((user_id = 18059) AND (is_deleted = false))
               ->  Index Only Scan using repository_pkey on repository  (cost=0.28..8.30 rows=1 width=8)
                     Index Cond: (id = action.repo_id)
(8 rows)

It just makes no sense to me that it would not use the index. That's why we have an index. Even the "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted) should have been enough.

The problem is order by ...

Here the plan without this: https://explain.depesz.com/s/ygq3

@somera
Copy link
Author

somera commented Sep 2, 2022

giteadb=# \d action
                                          Tabelle »public.action«
    Spalte    |          Typ           | Sortierfolge | NULL erlaubt? |            Vorgabewert
--------------+------------------------+--------------+---------------+------------------------------------
 id           | bigint                 |              | not null      | nextval('action_id_seq'::regclass)
 user_id      | bigint                 |              |               |
 op_type      | integer                |              |               |
 act_user_id  | bigint                 |              |               |
 repo_id      | bigint                 |              |               |
 comment_id   | bigint                 |              |               |
 is_deleted   | boolean                |              | not null      | false
 ref_name     | character varying(255) |              |               |
 is_private   | boolean                |              | not null      | false
 content      | text                   |              |               |
 created_unix | bigint                 |              |               |
Indexe:
    "action_pkey" PRIMARY KEY, btree (id)
    "IDX_action_au_r_c_u_d" btree (act_user_id, repo_id, created_unix, user_id, is_deleted)
    "IDX_action_comment_id" btree (comment_id)
    "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted)
    "action_created_unix_idx" btree (created_unix DESC)
    "action_user_id_idx" btree (user_id)

Looks better now (~600ms faster for the start page)

image

https://explain.depesz.com/s/K6u3

@somera
Copy link
Author

somera commented Sep 2, 2022

I remved

"action_user_id_idx" btree (user_id)

now.

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

What the hell is going on:

"Limit  (cost=0.71..19.21 rows=20 width=456) (actual time=0.088..0.371 rows=20 loops=1)"
"  ->  Nested Loop  (cost=0.71..604060.66 rows=653278 width=456) (actual time=0.085..0.358 rows=20 loops=1)"
"        ->  Index Scan using action_created_unix_idx on action  (cost=0.43..404005.15 rows=653278 width=456) (actual time=0.053..0.120 rows=20 loops=1)"
"              Filter: ((NOT is_deleted) AND (user_id = 1))"
"              Rows Removed by Filter: 20"
"        ->  Index Only Scan using repository_pkey on repository  (cost=0.29..0.31 rows=1 width=8) (actual time=0.009..0.009 rows=1 loops=20)"
"              Index Cond: (id = action.repo_id)"
"              Heap Fetches: 20"
"Planning Time: 1.418 ms"
"Execution Time: 0.457 ms"

Why would your db choose to use the index action_created_unix_idx!!

@somera
Copy link
Author

somera commented Sep 2, 2022

I don't know. ;)

My action table has 1.307.514 entries.

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

Maybe you'd benefit from:

CREATE INDEX IDX_action_c_u_d ON action (created_unix DESC, user_id, is_deleted)

Possibly even append an INCLUDE (repo_id) there.

@somera
Copy link
Author

somera commented Sep 2, 2022

Maybe you'd benefit from:

CREATE INDEX IDX_action_c_u_d ON action (created_unix DESC, user_id, is_deleted)

Possibly even append an INCLUDE (repo_id) there.

Indexe:
    "action_pkey" PRIMARY KEY, btree (id)
    "IDX_action_au_r_c_u_d" btree (act_user_id, repo_id, created_unix, user_id, is_deleted)
    "IDX_action_comment_id" btree (comment_id)
    "IDX_action_r_u_d" btree (repo_id, user_id, is_deleted)
    "idx_action_c_u_d" btree (created_unix DESC, user_id, is_deleted)

https://explain.depesz.com/s/YJuyr

The start page feels better.

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

Is that fast enough now?

@somera
Copy link
Author

somera commented Sep 2, 2022

Is that fast enough now?

Yes! Thx.

@somera
Copy link
Author

somera commented Sep 2, 2022

Should I remove the index

"idx_action_c_u_d" btree (created_unix DESC, user_id, is_deleted)

and wait for the fix release?

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

OK, now Gitea won't start up with those indexes like that due to a bug in xorm - so we have two problems:

  • We need to fix xorm to tolerate indexes that don't match the xorm pattern.
  • I guess we need to add this index by default
    • One problem is that xorm can't express DESCing indexes so we should check if the DESC is necessary
    • Another is that I'm not sure how applicable this index is to smaller dbs

My large "test" db "only" has 42569 rows in action so I guess this is why I didn't see this.

Could you check if this is still fast:

CREATE INDEX action_c_u_d ON action (created_unix, user_id, is_deleted)

If so that will make fixing this easier.

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

Yes you will need to remove the index or at least remove it in between restarts.

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

OK here's the XORM fix: https://gitea.com/xorm/xorm/pulls/2174

Now actually I think we should not drop irregular indices as it is likely that the user has added these deliberately but I guess we should discuss that in another PR.

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

@somera I've got a few more indexes to check:

CREATE "IDX_action_c_r_u_d" ON action (created_unix, repo_id, user_id, is_deleted)

and

CREATE "IDX_action_c_u_d_r" ON action (created_unix, user_id, is_deleted, repo_id)

If either of those are faster than IDX_action_c_u_d it would be helpful to know.

@somera
Copy link
Author

somera commented Sep 2, 2022

OK, now Gitea won't start up with those indexes like that due to a bug in xorm - so we have two problems:

  • We need to fix xorm to tolerate indexes that don't match the xorm pattern.

  • I guess we need to add this index by default

    • One problem is that xorm can't express DESCing indexes so we should check if the DESC is necessary
    • Another is that I'm not sure how applicable this index is to smaller dbs

My large "test" db "only" has 42569 rows in action so I guess this is why I didn't see this.

Could you check if this is still fast:

CREATE INDEX action_c_u_d ON action (created_unix, user_id, is_deleted)

If so that will make fixing this easier.

Sorry, I didn't see the question.

Here the plan for the index: https://explain.depesz.com/s/JfF9

But the speed is same like with: CREATE INDEX IDX_action_c_u_d ON action (created_unix DESC, user_id, is_deleted)

@zeripath
Copy link
Contributor

zeripath commented Sep 2, 2022

excellent so the DESC is unnecessary.

What about the repo_id containing ones?

zeripath added a commit to zeripath/gitea that referenced this issue Sep 2, 2022
In go-gitea#21031 we have discovered that on very big tables postgres will use a
search involving the sort term in preference to the restrictive index.

Therefore we add another index for postgres and update the original migration.

Fix go-gitea#21031

Signed-off-by: Andrew Thornton <art27@cantab.net>
@somera
Copy link
Author

somera commented Sep 2, 2022

excellent so the DESC is unnecessary.

What about the repo_id containing ones?

You mean the user with only one repo?

Works too. Some ms slower.

image

The plan: https://explain.depesz.com/s/CfHx

zeripath added a commit to zeripath/gitea that referenced this issue Sep 4, 2022
Backport go-gitea#21033

In go-gitea#21031 we have discovered that on very big tables postgres will use a
search involving the sort term in preference to the restrictive index.

Therefore we add another index for postgres and update the original migration.

Fix go-gitea#21031

Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath added a commit that referenced this issue Sep 4, 2022
Backport #21033

In #21031 we have discovered that on very big tables postgres will use a
search involving the sort term in preference to the restrictive index.

Therefore we add another index for postgres and update the original migration.

Fix #21031

Signed-off-by: Andrew Thornton <art27@cantab.net>
tyroneyeh added a commit to tyroneyeh/gitea that referenced this issue Sep 7, 2022
commit 32eef4a
Author: Lunny Xiao <xiaolunwen@gmail.com>
Date:   Wed Sep 7 05:32:20 2022 +0800

    Add changelog for v1.17.2 (go-gitea#21089)

    Co-authored-by: John Olheiser <john+github@jolheiser.com>
    Co-authored-by: 6543 <6543@obermui.de>
    Co-authored-by: delvh <dev.lh@web.de>
    Co-authored-by: techknowlogick <techknowlogick@gitea.io>

commit 449b39e
Author: Tyrone Yeh <tyrone_yeh@draytek.com>
Date:   Tue Sep 6 16:42:05 2022 +0800

    Fix sub folder in repository missing add file dropdown (go-gitea#21069) (go-gitea#21083)

    Backport go-gitea#21069

    In repository sub folder missing add file dropdown menu, Probably broken since go-gitea#20602

commit 06f968d
Author: zeripath <art27@cantab.net>
Date:   Tue Sep 6 07:54:47 2022 +0100

    Fix hard-coded timeout and error panic in API archive download endpoint (go-gitea#20925) (go-gitea#21051)

    Backport go-gitea#20925

    This commit updates the `GET /api/v1/repos/{owner}/{repo}/archive/{archive}`
    endpoint which prior to this PR had a couple of issues.

    1. The endpoint had a hard-coded 20s timeout for the archiver to complete after
       which a 500 (Internal Server Error) was returned to client. For a scripted
       API client there was no clear way of telling that the operation timed out and
       that it should retry.

    2. Whenever the timeout _did occur_, the code used to panic. This was caused by
       the API endpoint "delegating" to the same call path as the web, which uses a
       slightly different way of reporting errors (HTML rather than JSON for
       example).

       More specifically, `api/v1/repo/file.go#GetArchive` just called through to
       `web/repo/repo.go#Download`, which expects the `Context` to have a `Render`
       field set, but which is `nil` for API calls. Hence, a `nil` pointer error.

    The code addresses (1) by dropping the hard-coded timeout. Instead, any
    timeout/cancelation on the incoming `Context` is used.

    The code addresses (2) by updating the API endpoint to use a separate call path
    for the API-triggered archive download. This avoids producing HTML-errors on
    errors (it now produces JSON errors).

    Signed-off-by: Peter Gardfjäll <peter.gardfjall.work@gmail.com>

    Signed-off-by: Peter Gardfjäll <peter.gardfjall.work@gmail.com>
    Signed-off-by: Andrew Thornton <art27@cantab.net>
    Co-authored-by: Peter Gardfjäll <peter.gardfjall.work@gmail.com>
    Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>

commit 084797b
Author: Lunny Xiao <xiaolunwen@gmail.com>
Date:   Tue Sep 6 06:48:57 2022 +0800

    Fix delete user missed some comments (go-gitea#21067) (go-gitea#21068)

commit 7888a55
Author: zeripath <art27@cantab.net>
Date:   Sun Sep 4 17:17:48 2022 +0100

    Delete unreferenced packages when deleting a package version (go-gitea#20977) (go-gitea#21060)

    Backport go-gitea#20977

    Delete a package if its last version got deleted. Otherwise removing the owner works only after the clean up job ran.

    Fix go-gitea#20969

    Co-authored-by: KN4CK3R <admin@oldschoolhack.me>

commit ea416d7
Author: zeripath <art27@cantab.net>
Date:   Sun Sep 4 17:17:35 2022 +0100

    Redirect if user does not exist on admin pages (go-gitea#20981) (go-gitea#21059)

    Backport go-gitea#20981

    When on /admin/users/ endpoints if the user is no longer in the DB,
    redirect instead of causing a http 500.

    Co-authored-by: KN4CK3R <admin@oldschoolhack.me>

commit 0db6add
Author: zeripath <art27@cantab.net>
Date:   Sun Sep 4 17:17:27 2022 +0100

    Set uploadpack.allowFilter etc on gitea serv to enable partial clones with ssh (go-gitea#20902) (go-gitea#21058)

    Backport go-gitea#20902

    When setting.Git.DisablePartialClone is set to false then the web server will add filter support to web http. It does this by using`-c` command arguments but this will not work on gitea serv as the upload-pack and receive-pack commands do not support this.

    Instead we move these options into the .gitconfig instead.

    Fix go-gitea#20400

    Signed-off-by: Andrew Thornton <art27@cantab.net>

    Signed-off-by: Andrew Thornton <art27@cantab.net>

commit 0ecbb71
Author: qwerty287 <80460567+qwerty287@users.noreply.github.com>
Date:   Sun Sep 4 17:12:37 2022 +0200

    Fix 500 on time in timeline API (go-gitea#21052) (go-gitea#21057)

    Backport go-gitea#21052

    Before converting a TrackedTime for the API we need to load its attributes - otherwise we get an NPE.

    Fix go-gitea#21041

commit ea38455
Author: Jason Song <i@wolfogre.com>
Date:   Sun Sep 4 23:12:01 2022 +0800

    Fill the specified ref in webhook test payload (go-gitea#20961) (go-gitea#21055)

    Backport go-gitea#20961

    The webhook payload should use the right ref when it‘s specified in the testing request.

    The compare URL should not be empty, a URL like `compare/A...A` seems useless in most cases but is helpful when testing.

commit 8fc80b3
Author: zeripath <art27@cantab.net>
Date:   Sun Sep 4 16:11:02 2022 +0100

    Add another index for Action table on postgres (go-gitea#21033) (go-gitea#21054)

    Backport go-gitea#21033

    In go-gitea#21031 we have discovered that on very big tables postgres will use a
    search involving the sort term in preference to the restrictive index.

    Therefore we add another index for postgres and update the original migration.

    Fix go-gitea#21031

    Signed-off-by: Andrew Thornton <art27@cantab.net>

commit 71aa64a
Author: zeripath <art27@cantab.net>
Date:   Sun Sep 4 14:59:20 2022 +0100

    fix broken insecureskipverify handling in rediss connection uris (go-gitea#20967) (go-gitea#21053)

    Backport go-gitea#20967

    Currently, it's impossible to connect to self-signed TLS encrypted redis instances. The problem lies in inproper error handling, when building redis tls options - only invalid booleans are allowed to be used in `tlsConfig` builder. The problem is, when `strconv.ParseBool(...)` returns error, it always defaults to false - meaning it's impossible to set `tlsOptions.InsecureSkipVerify` to true.

    Fixes go-gitea#19213

    Co-authored-by: Igor Rzegocki <ajgon@users.noreply.github.com>

commit 3aba72c
Author: zeripath <art27@cantab.net>
Date:   Sun Sep 4 14:41:21 2022 +0100

    Add more checks in migration code (go-gitea#21011) (go-gitea#21050)

    Backport go-gitea#21011

    When migrating add several more important sanity checks:

    * SHAs must be SHAs
    * Refs must be valid Refs
    * URLs must be reasonable

    Signed-off-by: Andrew Thornton <art27@cantab.net>

commit bd1412c
Author: José Carlos <joecarlhr@gmail.com>
Date:   Sat Sep 3 21:11:03 2022 +0200

    Add Dev, Peer and Optional dependencies to npm PackageMetadataVersion (go-gitea#21017) (go-gitea#21044)

    Backport go-gitea#21017

    Set DevDependencies, PeerDependencies & OptionalDependencies in npm package metadatas

    Fix go-gitea#21013

commit 3973ce3
Author: silverwind <me@silverwind.io>
Date:   Sat Sep 3 19:51:09 2022 +0200

    Improve arc-green code theme (go-gitea#21039) (go-gitea#21042)

    Backport go-gitea#21039

    - Increase contrasts overall
    - Add various missing theme classes
    - Ensure strings and constants are colored the same across languages

commit fbde31f
Author: Tyrone Yeh <tyrone_yeh@draytek.com>
Date:   Sat Sep 3 21:36:27 2022 +0800

    Add down key check has tribute container (go-gitea#21016) (go-gitea#21038)

    Backport go-gitea#21016

    Fixes an issue where users would not be able to select by pressing the down arrow when using @tag above a message

    Bug videos:

    https://user-images.githubusercontent.com/1255041/188095999-c4ccde18-e53b-4251-8a14-d90c4042d768.mp4
@somera
Copy link
Author

somera commented Sep 7, 2022

Workx now fine with 1.17.2
image

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants