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

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.

Step 0 — preconditions

Step 1 — collapse the call sites

Read the value from automator main at HEAD — not from the rollout PR, the ticket, or the registered default; it may have moved since.

Stop and ask the user if either holds. Report the values you found and let them decide — do not pick a value and proceed:

• Regions disagree. options/default/ and the region files hold different values, so there is no single rolled-out outcome to collapse to. Which one wins, or whether the option should stay, is a product decision.
• The option is drifted ([DRIFT] in the automator run). The live value differs from the file, so the file is not the truth. Someone changed it through another channel, and the why matters before anything is deleted.

Otherwise collapse each call site to the outcome that won. Do not leave the value behind as an if True or a lone constant — that is the dead code the flag was supposed to retire. Two safe variants:

• Collapse the branch (default). Delete the options.get(...) / features.has(...) / organization.features.includes(...) condition, keep the branch that won, delete the branch that lost.
• Move the value into the registered default first. Change default= in defaults.py to the rolled-out value and deploy that before step 2, then collapse the call sites. Use when the option must stay readable during a longer transition.

Doing neither is the common mistake: step 2 then changes production behavior.

Sweep what the collapse orphans

The losing branch is rarely the only thing that dies. Delete:

• functions, components, serializers, and hooks reached only from the losing branch
• tests for the old path, plus with self.feature(...) blocks and mocked responses that now assert nothing
• fixtures, analytics events, styles, and types used only by the old path
• feature-gated route entries and navigation items

The gate for step 2 is only that no read of the option remains. If the sweep is large, land the collapse first and the deletions right behind it — a follow-up PR that touches no reads does not affect the ordering.

Step 2 — remove the value from the automator

What removal actually falls back to:

Check every file that sets it:

• Options: options/default/<file>.yaml and every options/regions/*/<file>.yaml. Region values clobber the default, so a leftover region entry keeps the option set there and breaks step 3.
• Flags: only options/default/flagpole.yaml. There are no per-region flagpole files.
• Watch for a default=True on the flag registration — that keeps it on after the YAML is gone.

Merge, then confirm the deploy is green in #feed-options-automator before step 3.

Step 3 — remove the registration

Delete the options.register(...) line from defaults.py, or the manager.add(...) line from temporary.py. For an api_expose=True flag this also drops it from the org serializer's features array, so any surviving frontend check silently evaluates false rather than erroring — which is why step 1's frontend PR must already be deployed.

Failure modes