Stale Feature-Flag Kill Switch
Checkout prices have started mismatching cart totals. Nothing was deployed today — nothing was deployed this week. The only thing that changed was an on-call engineer flipping an unrelated, seemingly-safe checkout layout flag for a routine rollout. Minutes later, a legacy pricing engine that was supposedly retired months ago started actively computing prices again. Its own kill switch was never actually removed — just forgotten — and the unrelated flag change woke it up as a side effect. Reverting the flag that triggered the wake-up will not put it back to sleep: that flag only controls whether the trigger fires again, not whether the legacy engine itself stays active. Trace the symptom back to the stale flag and disable it directly.
- Difficulty
- Intermediate
- Expected Time
- ~12 min
- Category
- Deployments & Reliability
Skills
- Distinguishing dormant flag debt from an immediate bad-deploy regression
- Tracing a symptom back to a stale flag rather than the change that merely triggered it
- Recognizing that reverting a trigger does not undo an already-latched side effect
- Verifying the actual root-cause flag is disabled, not just the proximate change
System Architecture
- Web Frontend
- Feature Flag Service
- Checkout Service
- Legacy Pricing Engine
- Pricing Cache
This is a Pro scenario. Upgrade to Pro to unlock it.
Upgrade to ProBack to Incidents