Adding multiple labels in pull / issue detail page broken

[noerw]

• Gitea version (or commit ref): 1.14.0+dev-290-gb1cf7f4df (current gitea.com)

• Git version: ? (current gitea.com)

• Operating system: ? (current gitea.com)

• Database (use [x]): (current gitea.com)

  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite

• Can you reproduce the bug at https://try.gitea.io:

  • Yes (provide example URL):
  • No, only on gitea.com https://gitea.com/gitea/tea/pulls/285

• Log gist:

Description

1. Opening the label dropdown and selecting more than one label applies only one of the selected labels. Sometimes two, not consistent. So far never all selected labels.

2. Doing this several times adds the remaining labels, but in the action log / comments of the issue, only the first added label is displayed.

I didn't check in detail, but 2. makes me think this was introduced by #13304.
Another recent bug related to labels is #13688

Screenshots

[lunny]

May also related with #13619

[silverwind]

Not sure if related but I noticed when adding a single label and trying to "Clear Labels", it does not work. Label is temporarily removed but get's re-added again from the server response.

[noerw]

A new interesting sample on this, might be another labels bug..

• I created https://gitea.com/gitea/tea/pulls/327, and labeled it as kind/bug. The label is not shown in the PR comment log (as described in OP)
  
• Unlike the PR detail view, the PR list also shows the kind/enhancement label. Filtering by that label reveals the label ID 4694.
  
• Other PRs intentionally labeled kind/enhancement have label ID 435 for that.

gitea.com currently runs 1.14.0+dev-754-g5d2b7ba63

[CirnoT]

Unsure if this should be closed as it raises two separate issue. #14894 fixes display issue for event-timeline but this issue also tracks case where label is not added at all server-side.

[zeripath]

OK - I think we need to retest and show that the issue is still happening on try/master

[lunny]

I can see both https://gitea.com/gitea/tea/pulls/285 and https://gitea.com/gitea/tea/pulls/327 's problem resolved.

[lunny]

OK. The problem left is here.

• Unlike the PR detail view, the PR list also shows the kind/enhancement label. Filtering by that label reveals the label ID 4694.
  
• Other PRs intentionally labeled kind/enhancement have label ID 435 for that.

gitea.com currently runs 1.14.0+dev-754-g5d2b7ba63

[noerw]

OK. The problem left is here.

• Unlike the PR detail view, the PR list also shows the kind/enhancement label. Filtering by that label reveals the label ID 4694.

For new issues this doesnt happen anymore, so I think this is because the bug previously persisted those extra labels to DB.
I guess a heuristic to clean the DB would be to remove rows where labelID > 4000 (and maybe only for issues from last 12 days)

[CirnoT]

The fix applied did nothing to change what label ID is saved to database, it only fixed squashing multiple actions into one timeline event.

The ID discrepancy will most likely be because of repo vs org label. I'm gonna guess both tea repo and gitea org have kind/enhancement label and some parts of code use one, while others the other (possibly tea tool explicitly tells Gitea to apply the other one)

[Toxik1983]

I believe this bug has existed since before 1.13.0.

Not only does this happen when adding multiple labels at once, but also when removing them at the same time.
For example, if you swap labels by removing one and adding the other, this will only perform one of the two actions.
Most of the time, you need to refresh the page for this to become apparant.

Currently, in order to set or remove multiple labels reliably, you must blur the dialog in between each alteration.

[fnetX]

Not sure if this is new information to anyone here (didn't look in all the mentioned PRs), but this is also tracked at Codeberg with some log output: https://codeberg.org/Codeberg/Community/issues/123#issuecomment-77816
(https://codeberg-test.org/fnx/general/issues/1#issuecomment-95)

[wxiaoguang]

Deadlock problem is related to this one:

• Batch calling of updateIssuesMeta causes database deadlock #17469

I think it can be fixed in 1.16

[lunny]

I think this has been resolved.