Skip to content

fix: retry note creation when rate limited - #1039

Open
elwynelwyn wants to merge 1 commit into
semantic-release:masterfrom
elwynelwyn:fix/retry-rate-limited-comments
Open

elwynelwyn wants to merge 1 commit into
semantic-release:masterfrom
elwynelwyn:fix/retry-rate-limited-comments

Conversation

@elwynelwyn

@elwynelwyn elwynelwyn commented Oct 23, 2026 •

Copy link
Copy Markdown

Problem this solves

Comments posted by the success step are never retried when GitLab rate limits them, so large releases fail with 429 Too Many Requests after the release has already been published.

Our team is experiencing this issue, documented here: https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/work_items/3358

Example failing job:

HTTPError: Request failed with status code 429 (Too Many Requests): POST https://gitlab.com/api/v4/projects/46519181/merge_requests/4331/notes
  retry: {
    limit: 3,
    methods: [ 'GET', 'PUT', 'HEAD', 'DELETE', 'OPTIONS', 'TRACE' ],
  ...
  method: 'POST'

This is because got's default retry.methods doesn't include POST, so the note creation requests do not ever retry.

GitLab.com allows 60 note creations per minute per user, and the plugin posts every comment at once, so any release touching more than ~60 issues/MRs hits it.

The fix

This PR gives the two note POSTs their own retry config that allows POST, but only on 429:

  • GitLab checks the note rate limit before creating the note (lib/api/notes.rb), so a 429 is safe to retry and won't duplicate a comment.
  • GitLab 18.5+ sends Retry-After: 60 (the full window) with that 429, which got already honours, so the retry lands in a fresh window.
  • 5xx responses and network errors aren't retried, since the note may have been saved.

The existing got retry handling of 429s remains unchanged - it will now also apply it to these requests.

Limitations:

  • With the default retryLimit: 3 this covers up to ~240 comments per release on GitLab.com. Bigger releases can raise retryLimit.
  • GitLab < 18.5 doesn't send Retry-After for this limit, so got falls back to its 1s/2s/4s backoff. That's the same failure as today, just ~7s later (self-managed defaults to 300/min, so it's less likely to come up).

Related issues

Follow-up to #361 and #728.

How has this been tested?

  • New tests: comments retry after a 429 with Retry-After, and aren't retried after a 500
  • The retry test fails without the fix, with the same 429 ... POST .../notes error as above

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant