What if I archive a flag still used in my code?

Last updated:

Archiving removes the flag from the configuration SDKs receive, so every remaining call site immediately falls back to the default value passed at that call site. Nothing throws and nothing logs an error, because the SDK cannot tell an archived flag from one that never existed. Remove the code first, then archive.

Archiving is a configuration change with a runtime effect, which is easy to miss because the word sounds like filing something away.

The configuration served to SDKs excludes archived flags. Within seconds of archiving, connected clients hold a snapshot that no longer contains the key, and every call site for it starts returning its default.

Why this is silent

An SDK has no way to distinguish an archived flag from a typo. Both are keys absent from the snapshot, both report flag-not-found, and both return the default rather than raising. The safety property that keeps your app running during an outage is the same one that hides this.

So the failure mode is behavioural, not an exception. Whatever your default happens to be is what every user now gets.

Which means the default matters

// Archived flag, code still present
client.boolVariation('new-checkout', false); // -> false, feature off

If the flag was fully rolled out and the code still passes false as the default, archiving it turns the feature off for everyone. The rollout said 100%, the archive said otherwise, and nothing in between complained.

The order that works

  1. Roll the flag to 100% and let it sit until you trust it.
  2. Delete the flag from the code, keeping the winning branch.
  3. Deploy and confirm nothing references the key.
  4. Archive the flag.

Step 3 is the one people skip. Grep for the key across the repository, including tests, config and any other service that shares the project.

Featureflip will not archive anything for you

Stale and dead flag detection is a signal, deliberately. Nothing archives, disables, or deletes a flag automatically, precisely because the runtime consequence above is real and the decision needs a person who knows whether the code is gone.

If you archived too early

Restore it. The flag returns to the configuration with its settings intact and call sites resume evaluating normally. Fix the ordering, then archive again.

Detection and the flag lifecycle are documented in Stale flag detection, and fallback behaviour in Reliability and resilience.

Still stuck?

The docs cover every SDK, and the free Solo plan is enough to reproduce most of these locally.