Multiple labels for an issue can't be choose at the same time #123

Open
opened 2 years ago by Booteille · 28 comments

Each time I want to add multiple labels to an issue, I must open the label popup, select a label, click anywhere on the page to close the popup, then open the popup again and repeat actions to every other label I want to add.

Simply selecting at the same time multiple labels does not seem to be taken into account.

Each time I want to add multiple labels to an issue, I must open the label popup, select a label, click anywhere on the page to close the popup, then open the popup again and repeat actions to every other label I want to add. Simply selecting at the same time multiple labels does not seem to be taken into account.
hw added
gitea-related
contribution welcome
enhancement
and removed
enhancement
labels 2 years ago
hw commented 2 years ago
Owner

Seems like a gitea bug .. is this already reported upstream?

Seems like a gitea bug .. is this already reported upstream?
hw added the
bug
label 2 years ago
Owner

@Booteille
This bug already closed upstream in gitea 1.11, just tested it.
We will migrate soon, so this will be resolved then.

@Booteille This bug already closed upstream in gitea 1.11, just tested it. We will migrate soon, so this will be resolved then.
hw commented 2 years ago
Owner

Thank you for reporting. Should be fixed. Can you please test?

Thank you for reporting. Should be fixed. Can you please test?
Poster

Thank you for reporting. Should be fixed. Can you please test?

It does not seem to have been fixed. (But maybe you just didn't migrate already)
Where can I find the actual version of Codeberg?

> Thank you for reporting. Should be fixed. Can you please test? It does not seem to have been fixed. (But maybe you just didn't migrate already) Where can I find the actual version of Codeberg?
hw added
enhancement
and removed
enhancement
labels 2 years ago
hw commented 2 years ago
Owner

Ok, we need to look further into this. We are currently running the 1.11 prerelease branch with additional fixes.

Ok, we need to look further into this. We are currently running the 1.11 prerelease branch with additional fixes.
ashimokawa added
enhancement
enhancement
and removed
enhancement
enhancement
labels 2 years ago
Owner

Hmm, strange, it worked on codeberg-test.org, but here it does not indeed. Could be also browser related. Need to investigate more.

Hmm, strange, it worked on codeberg-test.org, but here it does not indeed. Could be also browser related. Need to investigate more.

The problem still exists (Browser: Firefox 68 ESR). The cause may be that the issue page gets reloaded every time one of the labels in the label selector is checked or unchecked. If the issue page has to be reloaded, the browser should wait with that until the label selector is closed and all changes to the label selection have been saved.

The problem still exists (Browser: Firefox 68 ESR). The cause may be that the issue page gets reloaded every time one of the labels in the label selector is checked or unchecked. If the issue page has to be reloaded, the browser should wait with that until the label selector is closed and all changes to the label selection have been saved.
Owner

I can confirm this problem, getting this

2020/08/26 11:52:23 .../repo/issue_label.go:197:UpdateIssueLabel() [E] AddLabel: Error 1213: Deadlock found when trying to get lock; try restarting transaction
2020/08/26 11:52:23 .../repo/issue_label.go:197:UpdateIssueLabel() [E] AddLabel: Error 1213: Deadlock found when trying to get lock; try restarting transaction
I can confirm this problem, getting this ``` 2020/08/26 11:52:23 .../repo/issue_label.go:197:UpdateIssueLabel() [E] AddLabel: Error 1213: Deadlock found when trying to get lock; try restarting transaction 2020/08/26 11:52:23 .../repo/issue_label.go:197:UpdateIssueLabel() [E] AddLabel: Error 1213: Deadlock found when trying to get lock; try restarting transaction ```
Collaborator

o no - I had 👀 some time ago on parts of this code :/ - fixed unintentional overwrites there, now it's a DB deadlock

o no - I had :eyes: some time ago on parts of this code :/ - fixed unintentional overwrites there, now it's a DB deadlock
Collaborator

(firt thougt it has to do with frontend 😅: NOP)

(firt thougt it has to do with frontend 😅: NOP)
Owner

@6543
Btw, I cannot reproduce it on try.gitea.io

@6543 Btw, I cannot reproduce it on try.gitea.io
6543 added
duplicate
and removed
duplicate
labels 11 months ago
Collaborator

try is on master - it could be a 1.12.x only bug

try is on master - it could be a 1.12.x only bug
Collaborator

@ashimokawa bug is on v1.13 too

there are two solutions:

  1. change the js code to submit lable chois on click (there is time between each de-/selection) <- like asignee selection work
  2. make router endpoint accept a bundle of lable-id's at once
@ashimokawa bug is on v1.13 too there are two solutions: 1. change the js code to submit lable chois on click (there is time between each de-/selection) <- like asignee selection work 2. make router endpoint accept a bundle of lable-id's at once
Collaborator
upstream issue: https://github.com/go-gitea/gitea/issues/12643
6543 added
question
legal
and removed
question
legal
labels 10 months ago
Collaborator

ok this issue still exist in 1.12.5 as tested above - but it do not ocure in upstream anymore :/

so with release of v1.13.0 we will be able to close this ...
(upstream issue closed)

ok this issue still exist in **1.12.5** as tested above - but it do not ocure in upstream anymore :/ so with release of v1.13.0 we will be able to close this ... (upstream issue closed)
6543 added
question
wontfix
legal
and removed
question
wontfix
legal
labels 8 months ago
6543 closed this issue 8 months ago

I hope it fits into this issue.

Scenario (Steps to reproduce)

Me (or someone else) created an issue. I want to add multiple labels to this issue (for example complexity-3 and bug) so that I know what kind of issue this is.

Steps to reproduce:

  1. Create an Issue (Add title and then press create issue)
  2. Choose several labels and then reload the page

Expected behaviour

After reloading the page I'd expect that all the chosen labels are set. With Upstream-gitea I can also click somewhere in the page and all labels will be added.

Actual behaviour

At the moment only one label will be set (couldn't really find out which one as it changed. Sometimes it was the first label and sometimes another one)

Comparison to Gitea

I have tested the same thing on another gitea instance which runs this gitea version: 1.15.0+dev-56-gbc1f2117f
There it worked as expected so I think it's not an upstream issue.

I hope it fits into this issue. ## Scenario (Steps to reproduce) Me (or someone else) created an issue. I want to add multiple labels to this issue (for example `complexity-3` and `bug`) so that I know what kind of issue this is. Steps to reproduce: 1. Create an Issue (Add title and then press `create issue`) 2. Choose several labels and then reload the page ## Expected behaviour After reloading the page I'd expect that all the chosen labels are set. With Upstream-gitea I can also click somewhere in the page and all labels will be added. ## Actual behaviour At the moment only one label will be set (couldn't really find out which one as it changed. Sometimes it was the first label and sometimes another one) ## Comparison to Gitea I have tested the same thing on another gitea instance which runs this gitea version: 1.15.0+dev-56-gbc1f2117f There it worked as expected so I think it's not an upstream issue.
6543 reopened this issue 4 months ago
Collaborator

Can confirm this does not work for already existent issues, but works upon creation (before you post the issue). If you select one label, it will reload the page and add the label. If you select multiple ones, nothing will happen and after a reload, one of them is set (from my observation usually the last one)

Can confirm this does *not* work for already existent issues, but works upon creation (before you post the issue). If you select one label, it will reload the page and add the label. If you select multiple ones, nothing will happen and after a reload, one of them is set (from my observation usually the last one)
Collaborator

also on testing instance https://codeberg-test.org/fnx/general/issues/1 ← added some more observation there, but no breaking news I guess

but upstream looks working again https://try.gitea.io/fnetx/general/issues/2
I have a déjà-vu

also on testing instance https://codeberg-test.org/fnx/general/issues/1 ← added some more observation there, but no breaking news I guess but upstream looks working *again* https://try.gitea.io/fnetx/general/issues/2 I have a déjà-vu
Collaborator

Not a Gitea 1.14 but a Codeberg thing! Confirmed everything is fine on another 1.14.1 instance

Not a Gitea 1.14 but a Codeberg thing! Confirmed everything is fine [on another 1.14.1 instance](https://git.sdf.org/trelel_duude/testingtestingtesting/issues/1)
Collaborator

I just re-checked this and it works as expected. One can select multiple labels at once in an existing issue.

Can anyone confirm?

I just re-checked this and it works as expected. One can select multiple labels at once in an existing issue. Can anyone confirm?
n commented 2 months ago
Collaborator

Still having trouble with this. If I select more than one label, none show up in the UI, and then once reloaded only the first selected shows up.

Still having trouble with this. If I select more than one label, none show up in the UI, and then once reloaded only the first selected shows up.
Collaborator

This is some sort of server side issue, the requests sometimes return a 500:
image

This also affects the "Clear Labels" function.

This is some sort of server side issue, the requests sometimes return a 500: ![image](/attachments/f6771d46-55c4-45fd-a05a-1019b6c3473b) This also affects the "Clear Labels" function.
Collaborator

Yes, look at the first link of this comment: #123

I reproduced and even shared an excerpt from the server log for this. It doesn't happen upstream, so apparently we have to look into this ourself. Or maybe @6543 has got a free minute? 😅

Yes, look at the first link of this comment: https://codeberg.org/Codeberg/Community/issues/123#issuecomment-193188 I reproduced and even shared an excerpt from the server log for this. It doesn't happen upstream, so apparently we have to look into this ourself. Or maybe @6543 has got a free minute? 😅
Owner

I think it is my fault. Will try a fix

Edit: no, not what I thought :(

I think it is my fault. Will try a fix Edit: no, not what I thought :(
Collaborator

Will make some tests ...

Will make some tests ...
Collaborator

could reproduce it on upstream master somehow, but did not cat the real issue behind, it's some kind of deadlock or race condition that hapens on the backend ...

could reproduce it on upstream master somehow, but did not cat the real issue behind, it's some kind of deadlock or race condition that hapens on the backend ...
Collaborator

https://github.com/go-gitea/gitea/issues/13923 is another upstream issue for this

https://github.com/go-gitea/gitea/issues/13923 is another upstream issue for this
fnetX added this to the Summer 2021 milestone 2 months ago
Collaborator

I was playing around with this tonight until I got tired, but I think I didn't come up with many new information (so only sharing here, mainly for own documentation). I didn't find any consistency in what is locked, the messages appear somewhat unsteady and I can't see any correlation to what I'm doing in the GUI (apart from the different triggered function names of course)

2021/06/13 12:48:52 Started POST /otto/test/issues/labels for 127.0.0.1:51982
2021/06/13 12:48:52 Started POST /otto/test/issues/labels for 127.0.0.1:52002
2021/06/13 12:48:52 Started POST /otto/test/issues/labels for 127.0.0.1:52004
2021/06/13 12:48:52 Started POST /otto/test/issues/labels for 127.0.0.1:51904
2021/06/13 12:48:52 .../repo/issue_label.go:208:UpdateIssueLabel() [E] RemoveLabel: database table is locked: comment
2021/06/13 12:48:52 Completed POST /otto/test/issues/labels 500 Internal Server Error in 34.347527ms
2021/06/13 12:48:52 .../repo/issue_label.go:208:UpdateIssueLabel() [E] RemoveLabel: database table is locked
2021/06/13 12:48:52 .../repo/issue_label.go:208:UpdateIssueLabel() [E] RemoveLabel: database table is locked
2021/06/13 12:48:52 Completed POST /otto/test/issues/labels 500 Internal Server Error in 71.878839ms
2021/06/13 12:48:52 Completed POST /otto/test/issues/labels 200 OK in 223.842449ms
2021/06/13 12:48:52 Completed POST /otto/test/issues/labels 500 Internal Server Error in 226.50569ms
2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:51904
2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:52000
2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:52002
2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:51900
2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:51998
2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:51982
2021/06/13 12:48:33 ...rs/web/repo/issue.go:1651:getActionIssues() [E] LoadAttributes: database table is locked
2021/06/13 12:48:33 ...rs/web/repo/issue.go:1651:getActionIssues() [E] LoadAttributes: database table is locked
2021/06/13 12:48:33 ...user/notification.go:38:func1() [E] GetNotificationCount: database table is locked
2021/06/13 12:48:33 ...ules/context/repo.go:469:RepoAssignment() [E] GetReleaseCountByRepoID: database table is locked
2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 500 Internal Server Error in 54.550742ms
2021/06/13 12:48:33 ...user/notification.go:38:func1() [E] GetNotificationCount: database table is locked
2021/06/13 12:48:33 ...user/notification.go:38:func1() [E] GetNotificationCount: database table is locked
models/issue_label / 646oops
2021/06/13 12:48:33 .../repo/issue_label.go:201:UpdateIssueLabel() [E] AddLabel: database table is locked: comment
2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 500 Internal Server Error in 64.118894ms
2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 500 Internal Server Error in 68.855485ms
2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 500 Internal Server Error in 68.130966ms
models/issue_label / 646oops
2021/06/13 12:48:33 .../repo/issue_label.go:201:UpdateIssueLabel() [E] AddLabel: database table is locked: comment
2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 500 Internal Server Error in 81.785905ms
2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 200 OK in 325.700339ms

(Some log messages are custom, e.g. in latest 1.15 at the moment, I checked whether the models/issue_label.go triggers an error in line 646, but it triggers errors in pretty much any database-related function, but still not always. I don't really understand XORM here and why it apparently has so bad locking issues with insert statements, I haven't encountered them with any other framework yet in this frequency, also the introduced SQLITE timeout that was about to do any better doesn't help, I'm seeing error locks before the 500ms timeout AFAICT. Also, please note that this behaviour was reproduced with SQLite, it behaves a little different in MySQL, but I wanted to see if I could find more information with using SQLite for this, since MySQL only seemed to return the final deadlock without naming which tables are affected. I'm not sure if I'm wrong assuming that the table locks made by the framework are about the same with both SQL backends.

Lastly, I'm wondering why there are functions in place to update multiple labels at once, but not used. I think this might be a good first step to rewire the frontend to make use of them and at least avoid the deadlocks when a single user works in an issue.

Oh, and it looks like the deadlocks also affect other functions, not sure if this also creates other bugs somewhere?

Edit: The log excerpt only shows database locks for some tables, but I encountered many of them, including

  • none mentioned (<function>: database table is locked)
  • label
  • comment (seems to be most frequent so far)
  • issue
  • issue_kabel
I was playing around with this tonight until I got tired, but I think I didn't come up with many new information (so only sharing here, mainly for own documentation). I didn't find any consistency in what is locked, the messages appear somewhat unsteady and I can't see any correlation to what I'm doing in the GUI (apart from the different triggered function names of course) ~~~ 2021/06/13 12:48:52 Started POST /otto/test/issues/labels for 127.0.0.1:51982 2021/06/13 12:48:52 Started POST /otto/test/issues/labels for 127.0.0.1:52002 2021/06/13 12:48:52 Started POST /otto/test/issues/labels for 127.0.0.1:52004 2021/06/13 12:48:52 Started POST /otto/test/issues/labels for 127.0.0.1:51904 2021/06/13 12:48:52 .../repo/issue_label.go:208:UpdateIssueLabel() [E] RemoveLabel: database table is locked: comment 2021/06/13 12:48:52 Completed POST /otto/test/issues/labels 500 Internal Server Error in 34.347527ms 2021/06/13 12:48:52 .../repo/issue_label.go:208:UpdateIssueLabel() [E] RemoveLabel: database table is locked 2021/06/13 12:48:52 .../repo/issue_label.go:208:UpdateIssueLabel() [E] RemoveLabel: database table is locked 2021/06/13 12:48:52 Completed POST /otto/test/issues/labels 500 Internal Server Error in 71.878839ms 2021/06/13 12:48:52 Completed POST /otto/test/issues/labels 200 OK in 223.842449ms 2021/06/13 12:48:52 Completed POST /otto/test/issues/labels 500 Internal Server Error in 226.50569ms 2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:51904 2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:52000 2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:52002 2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:51900 2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:51998 2021/06/13 12:48:33 Started POST /otto/test/issues/labels for 127.0.0.1:51982 2021/06/13 12:48:33 ...rs/web/repo/issue.go:1651:getActionIssues() [E] LoadAttributes: database table is locked 2021/06/13 12:48:33 ...rs/web/repo/issue.go:1651:getActionIssues() [E] LoadAttributes: database table is locked 2021/06/13 12:48:33 ...user/notification.go:38:func1() [E] GetNotificationCount: database table is locked 2021/06/13 12:48:33 ...ules/context/repo.go:469:RepoAssignment() [E] GetReleaseCountByRepoID: database table is locked 2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 500 Internal Server Error in 54.550742ms 2021/06/13 12:48:33 ...user/notification.go:38:func1() [E] GetNotificationCount: database table is locked 2021/06/13 12:48:33 ...user/notification.go:38:func1() [E] GetNotificationCount: database table is locked models/issue_label / 646oops 2021/06/13 12:48:33 .../repo/issue_label.go:201:UpdateIssueLabel() [E] AddLabel: database table is locked: comment 2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 500 Internal Server Error in 64.118894ms 2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 500 Internal Server Error in 68.855485ms 2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 500 Internal Server Error in 68.130966ms models/issue_label / 646oops 2021/06/13 12:48:33 .../repo/issue_label.go:201:UpdateIssueLabel() [E] AddLabel: database table is locked: comment 2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 500 Internal Server Error in 81.785905ms 2021/06/13 12:48:33 Completed POST /otto/test/issues/labels 200 OK in 325.700339ms ~~~ (Some log messages are custom, e.g. in latest 1.15 at the moment, I checked whether the models/issue_label.go triggers an error in line 646, but it triggers errors in pretty much any database-related function, but still not always. I don't really understand XORM here and why it apparently has so bad locking issues with insert statements, I haven't encountered them with any other framework yet in this frequency, also the introduced SQLITE timeout that was about to do any better doesn't help, I'm seeing error locks before the 500ms timeout AFAICT. Also, please note that this behaviour was reproduced with SQLite, it behaves a little different in MySQL, but I wanted to see if I could find more information with using SQLite for this, since MySQL only seemed to return the final deadlock without naming which tables are affected. I'm not sure if I'm wrong assuming that the table locks made by the framework are about the same with both SQL backends. Lastly, I'm wondering why there are functions in place to update multiple labels at once, but not used. I think this might be a good first step to rewire the frontend to make use of them and at least avoid the deadlocks when a single user works in an issue. Oh, and it looks like the deadlocks also affect other functions, not sure if this also creates other bugs somewhere? Edit: The log excerpt only shows database locks for some tables, but I encountered many of them, including - none mentioned (`<function>: database table is locked`) - `label` - `comment` (seems to be most frequent so far) - `issue` - `issue_kabel`
Sign in to join this conversation.
No Milestone
No Assignees
9 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.