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 use the same order, for a different reason. Flag definitions no longer go through configoptions: the automator symlinks options/default/flagpole.yaml into the getsentry-features sentry-options namespace, and getsentry evaluates flags from that namespace. manager.add(..., FeatureHandlerStrategy.FLAGPOLE) only puts the name in features.default_manager.flagpole_features; nothing registers a feature.<name> option or checks the YAML against registrations. So a wrong order silently changes flag results rather than turning CI red, and a forgotten YAML block stays behind unnoticed.
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.