## Closing Statement GraphQL changes on both backend and frontend require following a specific process, otherwise our canary deployment breaks (more info in this epic's description below). Devs are warned about the process when the system detects that they are about to do these kinds of changes to GraphQL, but the warning wasn't very visible or actionable. What has been done: * **The warning is easier to notice** ([#607498](https://gitlab.com/gitlab-org/gitlab/-/work_items/607498), [!247826](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/247826)): the message now appears in the Warnings summary at the top of Dangerbot's comment instead of buried at the bottom. Wording has also been improved. * **Feedback arrives before the MR exists** ([#607500](https://gitlab.com/gitlab-org/gitlab/-/work_items/607500), [!248109](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/248109)): devs are now also warned when they are pushing these changes from their local environment, not only by Dangerbot in the MR. * **Detection gaps closed** ([#607501](https://gitlab.com/gitlab-org/gitlab/-/work_items/607501), [!248320](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/248320)): an edge case that used to not get caught by our automation gets now caught, and as a consequence the dev receives the relevant warnings. ## DRI @abignotti ## Problem All GraphQL requests use the same path (`/api/graphql`), so they cannot be routed to the canary backend the way path-based API requests are. During a rolling deploy a new canary frontend lands on an old main backend \~95% of the time. An MR that changes both a GraphQL schema and the frontend consuming it can therefore break canary — this caused [INC-1265](https://app.incident.io/gitlab/incidents/1265) (from https://gitlab.com/gitlab-org/gitlab/-/merge_requests/191475) and [INC-1276](https://app.incident.io/gitlab/incidents/1276) (from https://gitlab.com/gitlab-org/gitlab/-/merge_requests/185081). The only guardrail is a Dangerbot check (`tooling/danger/multiversion.rb`), and it has two weaknesses: the message is appended low in Dangerbot's single summary comment where it is easy to miss, and its purely path-based detection stays silent on several kinds of risky change. ## Goal Make the existing warning noticeable and accurate, so authors see the risk and know what to do before merging. All items stay non-blocking — combined frontend + backend changes are sometimes legitimate (feature-flagged, reverts, unrelated frontend edits). Three issues, in priority order: 1. **Make the warning easier to notice** — switch the check from Dangerbot's `markdown` helper to `warn`, which promotes it into the Warnings summary at the top of the comment. Also reword the message, which currently talks only about new _fields_ while both incidents were caused by new _arguments_. 2. **Surface the warning earlier** — run the same detection at `git push` time as a local, non-blocking warning, so feedback arrives before the MR is created and is not buried in CI output. 3. **Close the detection gaps** — add `app/graphql/queries/` to the frontend paths (client-side query documents there are currently scored as backend changes), and detect schema changes made outside `app/graphql/` (\~19 types build fields by looping over lists under `app/models/`, \~96 enums take their values from model constants). ## Out of scope - Comparing an MR's frontend GraphQL usage against the currently-deployed schema. This is the only approach that would also catch a frontend-only MR merged ahead of its backend, but it needs access to the deployed schema and must parse the MR's queries — deferred as too expensive for now. - Measuring the check's false-positive rate. - A technical safety net for new arguments. GraphQL directives cannot attach to arguments, so there is no equivalent to `@gl_introduced`; arguments stay a process concern (split and respect deploy order, or gate the frontend behind a feature flag). - Extending Duo's MR quality rules or an AI skill to flag/split these MRs ([suggested by @mwoolf](https://gitlab.com/gitlab-org/gitlab/-/work_items/545857#note_3622667607)) — worth revisiting once the three items above land. ## References - Investigation and discussion in https://gitlab.com/gitlab-org/gitlab/-/work_items/545857 <!-- STATUS NOTE START --> ## Status 2026-07-30 Just created the epic today and started working on the first issue. :tada: **achievements**: * Created [the first MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/247826) that makes the warning in the Dangerbot comment more prominent! :issue-blocked: **blockers**: * :arrow_forward: **next**: * Merge the MR that has just been opened and start working on another child issue, depending on other priorities. _Copied from https://gitlab.com/groups/gitlab-org/quality/-/epics/436#note_3623405900_ <!-- STATUS NOTE END -->