I opened a lot of community merge requests in the week of 2026-10-06 and hit three problems with `@gitlab-bot ready`. All three read as bugs in the code at [`1869266d`](https://gitlab.com/gitlab-org/quality/triage-ops/-/commit/1869266da0deb7d9ceecfac905d64ef83df7db96), and each one cost an author a second command and hours of waiting. The first also cost a reviewer a ping for a review they then lost. They are separate from who `ready` picks. !4447 changes that choice, which is the load question in gitlab-org/developer-relations/contributor-success/contributors-gitlab-com#787, and none of the code below is in its diff, so all three stay with it. Problem 1 would also stay if `ready` became a front for the contributor platform's picker, as suggested there, because the documentation processor's write replaces the list too. 1. **A reviewer is removed seconds after being requested.** Bot reviewer writes replace the whole list from a stale view, so one write erases the reviewer another one just added. It happened on 12 of my merge requests and on 9 merge requests by 8 other contributors in gitlab-org/gitlab that week. 2. **A `ready` sent before the diff exists never requests a reviewer.** The bot replies that it will wait 5 minutes, and then only marks the merge request ready. All 8 of my merge requests of 2026-10-07 took that path and none got a code reviewer. 3. **Some commands get no reply.** In projects with their own review process, and whenever the hourly limit is hit, the command returns without a word, even when it names a reviewer. What would fix them, all in triage-ops: - Add reviewers with `mergeRequestSetReviewers` and `operationMode: APPEND`, which merges with the current reviewers on the server, for `assign_reviewers_by_username` (the documentation processor, `help` and the gitlab-ui processor) and for the new reviewers `ready` writes. - In `ready`, write the reviewers before adding ~"workflow::ready for review", so the label event already carries them. - Have `MarkReadyForReviewJob` make the same review request as the immediate path, or say the diff is still empty. - Always answer once: one sentence in projects with their own process, and one reply per window when the limit is hit, saying when the command can be used again. <details> <summary>Evidence and code references</summary> **1. Race.** On my merge requests the requested reviewer was removed 1.4 to 7.9 seconds after the request (for example gitlab-org/gitlab!260668, gitlab-org/gitlab!260958, gitlab-org/gitlab!261569). On 5 of the 12 it was a reviewer I had named, and 7 needed a second `ready`, 1 to 51 hours later. The other contributors' cases come in two shapes: `ready` followed by the documentation processor (5), and the platform's review request with Duo, where the technical writer or GitLabDuo was dropped (4, for example gitlab-org/gitlab!261294). - `ready` adds the label ([`command_mr_request_review.rb` L69-70](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/processor/community/command_mr_request_review.rb#L69-70)) before it writes reviewers (L78). - `AutomatedReviewRequestDoc` reacts to that label and calls `assign_reviewers`, which PUTs `event.reviewer_ids` plus the writer ([`reaction.rb` L147-150](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/triage/reaction.rb#L147-150)). That payload predates the reviewer `ready` writes a second later. The processor appended with `/assign_reviewer` until 1a66c488 (!4315). - `ready` itself reads the reviewers and then PUTs the whole list ([`command_mr_request_review.rb` L110-117](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/processor/community/command_mr_request_review.rb#L110-117), [`reaction.rb` L155-157](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/triage/reaction.rb#L155-157)). The platform's review request with Duo adds the label and also carries `@gitlab-bot ready @GitLabDuo` in an HTML comment ([`manage_merge_request_controller.rb` L96-102](https://gitlab.com/gitlab-org/developer-relations/contributor-success/contributors-gitlab-com/-/blob/2a86231f3788b1b7d983aab2f9552c78eecb87c7/contributors/app/controllers/api/v1/manage_merge_request_controller.rb#L96-102)), so both writes run from one note and whichever writes last wins. - `APPEND` merges inside the resolver ([`set_reviewers.rb` L63-71](https://gitlab.com/gitlab-org/gitlab/-/blob/cebf7173e69fa4d7f4c83b28c5d7baae71b03419/app/graphql/mutations/merge_requests/set_reviewers.rb#L63-71)) and takes usernames. The GraphQL strategy `rerequest_review` uses already exists ([`graph_ql.rb` L24-33](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/triage/api_strategy/graph_ql.rb#L24-33)). REST has no additive form. **2. Delayed path.** The reply says "We will wait 5 minutes before assigning a reviewer" ([L82-91](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/processor/community/command_mr_request_review.rb#L82-91)), but `MarkReadyForReviewJob` only marks the merge request ready and adds the label ([`mark_ready_for_review_job.rb` L11-16](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/job/mark_ready_for_review_job.rb#L11-16)). The review request left the deferred path in 07d7b462 (!4198). Of my 8 merge requests of 2026-10-07 (for example gitlab-org/gitlab!260458, gitlab-org/gitlab!260486), 6 got only a technical writer and 2 got nobody and were moved back to ~"workflow::in dev". I sent a second, named `ready` on 6 of them, 2 to 12 hours later. **3. Silence.** Projects in `PROJECTS_WITH_EXTERNAL_REVIEW_PROCESSES` ([L23-33](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/processor/community/command_mr_request_review.rb#L23-33)) and Distribution projects ([L143-152](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/processor/community/command_mr_request_review.rb#L143-152)) return at [L72](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/processor/community/command_mr_request_review.rb#L72) after labelling. My six gemnasium-db merge requests and gitlab-org/charts/gitlab!5465 got no reply. A command over the hourly limit fails `applicable?` and is dropped with no reply ([`rate_limit.rb` L56-65](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/1869266da0deb7d9ceecfac905d64ef83df7db96/triage/triage/rate_limit.rb#L56-65)). **Related.** #1327 asks for feedback when a command does nothing in general. #1826 prefers `ready` requesting the technical writer itself, which would remove the first shape of problem 1 but not the one with Duo. My !4443 changes when `AutomatedReviewRequestDoc` runs, not how it writes, and its reviewer check reads the same `event.reviewer_ids`, so writing the reviewers before the label would also let that check see a writer named in `ready`. </details>