remove-option-or-flag
Remove a Sentry Option or Feature Flag
Removal takes three PRs in a fixed order, each deployed — not merely merged — before the next one merges. sentry and getsentry roll out region-by-region via GoCD; the automator runs its own pipeline. Wrong order either flips production behavior or turns the automator red on main for everyone.
FlagPole flags follow the same order for the same reason: registering a flag auto-registers an option feature.<flag-name> with FLAG_AUTOMATOR_MODIFIABLE (manager.py), so flags travel the identical configoptions path as options.
Order
| # | Repo | Change | Merge only after |
|---|---|---|---|
| 1 | sentry / getsentry | Collapse every read to the outcome that won; delete the dead branch | — |
| 2 | sentry-options-automator | Remove the value / flag block from YAML | step 1 deployed to all regions |
| 3 | sentry | Remove the registration (defaults.py / temporary.py) |
step 2 deployed, automator run green |
Step 1 is usually two PRs when a flag is read in both static/ and src/ — frontend and backend are not atomically deployed. That is the repo-wide rule in AGENTS.md, not an options-specific one; "step 1 deployed" therefore means both PRs are out.