Removal of issue label not reflected in webhook POST data #3572

New Issue

GiteaMirror · 2025-11-02T05:17:42-06:00

GiteaMirror commented

2025-11-02 05:17:42 -06:00

Originally created by @dodedodo on GitHub (Jul 11, 2019).

Gitea version (or commit ref):
- 1.8.3
Operating system:
- Alpine linux v3.10 hardened
Database
- MySQL (mariadb actually)
Can you reproduce the bug at https://try.gitea.io:
- Yes (https://try.gitea.io/testLabels/testLabels/issues/1)

How to reproduce

Step 1 Add label to issue
result: Webhook posts the issue data, including the right label information (the recently added label)

Step 2: Remove that same label (BUG)
result: Webhook posts the issue data, but this still includes the recently removed label! I'm expecting the webhook to remove the removed label from it's post data (issue.label).

Step 3: generate another webhook (like adding a comment)
result: The webhook provides the right label data again. So the label removed in step2 is not included in issue.labels

It looks like Gitea is sending it's webhook POST before it has actually updated the values internally. Because of this, te Gitea webhook is sending out-of-date information. A simple workaround is to request the labels when receiving the label_updated action, but that kind of defeats the purpose.

EDIT: this link actually shows the requests Gitea sent. Nice!

Originally created by @dodedodo on GitHub (Jul 11, 2019). - Gitea version (or commit ref): - 1.8.3 - Operating system: - Alpine linux v3.10 hardened - Database - [x] MySQL (mariadb actually) - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (https://try.gitea.io/testLabels/testLabels/issues/1) ## How to reproduce **Step 1 Add label to issue** result: Webhook posts the issue data, including the right label information (the recently added label) **Step 2: Remove that same label** _(BUG)_ result: Webhook posts the issue data, but this still includes the recently removed label! I'm expecting the webhook to remove the removed label from it's post data (issue.label). **Step 3: generate another webhook (like adding a comment)** result: The webhook provides the right label data again. So the label removed in step2 is not included in issue.labels --- It looks like Gitea is sending it's webhook POST before it has actually updated the values internally. Because of this, te Gitea webhook is sending out-of-date information. A simple workaround is to request the labels when receiving the label_updated action, but that kind of defeats the purpose. EDIT: [this link](https://try.gitea.io/testLabels/testLabels/settings/hooks/221) actually shows the requests Gitea sent. Nice! ![image](https://user-images.githubusercontent.com/3252036/61065307-b3ce2700-a403-11e9-8bc2-1209ab49709a.png)

GiteaMirror added the issue/confirmed type/bug labels 2025-11-02 05:17:42 -06:00

GiteaMirror closed this issue

2025-11-02 05:17:43 -06:00

GiteaMirror commented

2025-11-02 05:17:43 -06:00

@stale[bot] commented on GitHub (Sep 9, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Sep 9, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:17:43 -06:00

@davidsvantesson commented on GitHub (Sep 12, 2019):

I posted a similar issue (#7838). I think there are some cases for webhooks that the code write the new data to database, but the data served to the webhook is the old data. It could be solved by either writing the data to the structure as well before handling the webhook, or to reload the data from the database.

@davidsvantesson commented on GitHub (Sep 12, 2019): I posted a similar issue (#7838). I think there are some cases for webhooks that the code write the new data to database, but the data served to the webhook is the old data. It could be solved by either writing the data to the structure as well before handling the webhook, or to reload the data from the database.

GiteaMirror commented

2025-11-02 05:17:44 -06:00

@stale[bot] commented on GitHub (Nov 13, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Nov 13, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:17:44 -06:00

@stale[bot] commented on GitHub (Nov 27, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Nov 27, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror commented

2025-11-02 05:17:44 -06:00

@lunny commented on GitHub (Nov 28, 2019):

@dodedodo I want to know more detail about this issue and the repository on try site has been deleted.

Which gitea version were you using?
Which type webhook did you tested?

@lunny commented on GitHub (Nov 28, 2019): @dodedodo I want to know more detail about this issue and the repository on try site has been deleted. 1) Which gitea version were you using? 2) Which type webhook did you tested?

GiteaMirror commented

2025-11-02 05:17:44 -06:00

@guillep2k commented on GitHub (Nov 28, 2019):

I posted a similar issue (#7838). I think there are some cases for webhooks that the code write the new data to database, but the data served to the webhook is the old data. It could be solved by either writing the data to the structure as well before handling the webhook, or to reload the data from the database.

@davidsvantesson With the recent code refactoring that @lunny has been doing, I think this particular scenario should have been eliminated because one of the things he did was to move the webhook call outside of the model transaction. Unless of course some webhooks still require refactoring. All of this has been done in the 1.11 branch, however.

@guillep2k commented on GitHub (Nov 28, 2019): > > > I posted a similar issue (#7838). I think there are some cases for webhooks that the code write the new data to database, but the data served to the webhook is the old data. It could be solved by either writing the data to the structure as well before handling the webhook, or to reload the data from the database. @davidsvantesson With the recent code refactoring that @lunny has been doing, I think this particular scenario should have been eliminated because one of the things he did was to move the webhook call outside of the model transaction. Unless of course some webhooks still require refactoring. All of this has been done in the 1.11 branch, however.

GiteaMirror commented

2025-11-02 05:17:44 -06:00

@davidsvantesson commented on GitHub (Nov 28, 2019):

@guillep2k I have not worked on webhooks lately, might be that many update issues are solved.

@davidsvantesson commented on GitHub (Nov 28, 2019): @guillep2k I have not worked on webhooks lately, might be that many update issues are solved.

GiteaMirror commented

2025-11-02 05:17:45 -06:00

@b1tray3r commented on GitHub (Nov 3, 2020):

Hi all,

This should be fixed in 1.13.

Here is the PR: https://github.com/go-gitea/gitea/pull/13007

KR

Alex

@b1tray3r commented on GitHub (Nov 3, 2020): Hi all, This should be fixed in 1.13. Here is the PR: https://github.com/go-gitea/gitea/pull/13007 KR Alex

GiteaMirror referenced this issue

2025-11-02 12:24:03 -06:00

[PR #3572] [MERGED] Swagger.v1.json template #17005

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3572