Near-simultaneous changes to labels rewrite the whole label set, overwriting previous changes

[bluikko]

🏷️ Discussion Type

Product Feedback

Body

If different users make near-simultaneous changes to labels assigned to a PR, the latest change overwrites the whole label set. Example:

1. A PR has pre-existing labels: labelA labelB
2. Bot A adds: label1 and label2
3. User B in the web UI removes: labelA very shortly after step 2

Step 3 will remove label1, label2 and labelA. The PR has only labelB remaining.

The expectation would have been that the action in step 3 sends a "remove labelA from PR" request, instead of "reset all PR labels to label set in step 1 minus labelA. Wouldn't the intention of a user in the web UI be to either add/remove labels and not "reset all labels"? Maybe new APIs or syntax would be needed to add/remove labels instead of set labels?

Sometimes assigned labels need manual maintenance even if they are mostly automated.

Edit: add keywords for aiding in searching: concurrent concurrency race

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[asp53826]

The lost-update behavior is consistent with a stale read followed by a full-set write: whichever request arrives last replaces labels using an older snapshot and can discard a concurrent addition. The exact GitHub web implementation is not public, so that part is an inference from the result you observed.

For bots and scripts, new endpoints are not required. GitHub already exposes delta-style operations for pull requests through the Issues labels API:

# Add without replacing existing labels
gh api --method POST \
  repos/OWNER/REPO/issues/PR_NUMBER/labels \
  -f "labels[]=label1" \
  -f "labels[]=label2"

# Remove only one label; URL-encode the label name when needed
gh api --method DELETE \
  repos/OWNER/REPO/issues/PR_NUMBER/labels/labelA

The important distinction is:

• POST .../labels adds to the existing set.
• DELETE .../labels/{name} removes only that label.
• PUT .../labels sets the complete label set and therefore can overwrite concurrent changes.

So Bot A should use the additive endpoint, and any automation doing manual-style removals should use the single-label delete endpoint instead of read-modify-write. That prevents the common automation side of this race.

For the web UI case, the user cannot choose which endpoint GitHub sends. If the UI really submitted a stale complete set, that remains a valid GitHub concurrency bug/product-feedback issue. Until GitHub changes it, refreshing immediately before manual maintenance reduces the window; using the CLI delta operations above avoids it entirely.

Official reference: REST API endpoints for labels.

[bluikko]

Thanks, I have to admit I've not looked at the API docs in this area. That's why the question marks in the OP.

To be clear, it looked like the web UI change was the problematic one:
The PR shows the bot added labels just before 1 label was deleted from the web UI. Both showed timestamp "now" so I suspect the manual change in the web UI was done seconds after the bot.

Editing the labels is at the top of the PR page and the latest history is at the bottom of the page so there's also no warning that something just happened. Unless one has a gigantic screen in portrait mode.

It was very bad timing but I was very surprised and dismayed that the labels were reset especially when it was not my PR. I agree with what you say in the last paragraph.