What Remains After You Turn a Feature Off?

Separate a feature-flag switch from persisted records, queued work and external effects. Test reader compatibility and operation settlement before calling a release...

Inspect what the enabled path already changed

Turning a feature off changes the behavior of code that observes that flag. It does not by itself remove a persisted record, cancel an admitted job or reverse an external action. Before describing the switch as a rollback, identify the state that the enabled path produced and establish which running readers and workers can handle it safely.

Consider a hypothetical order service introducing split deliveries. The new path writes an order with two shipment allocations and queues a supplier notification. The old path expects one allocation. An operator turns off new split-delivery admission after finding a defect. Existing split orders, their reservations and the pending notification still exist. Returning the interface to its old appearance does not establish what the older fulfillment worker will do with those records.

This article proposes a release-recovery contract for that situation. The scenario is illustrative, not an Ampity customer result. A presentation-only flag may have little data consequence; a flag controlling a workflow needs a wider review. Decide the scope from what the enabled code can write and admit, rather than requiring the same recovery machinery for every display change.

Define the flag's reach and observation points

Inventory the places that evaluate the flag: the browser, request handler, worker, scheduled job and any other participating component. Record whether the decision is made when an operation starts or checked again before a consequential action. A worker carrying a previously accepted instruction may never consult the browser's flag. A cached decision may also remain in use after the control-plane value changes.

OpenFeature's flag-evaluation specification defines typed evaluation and detailed results, including default-value handling during abnormal evaluation. Some details are best effort. Our recommendation is to verify the application's chosen default and provider behavior at every relevant boundary. The specification is not a transaction manager and does not promise to reverse application data when a value changes.

Make the safe fallback explicit. In the hypothetical order service, failed flag evaluation must not accidentally admit the split-delivery capability if its compatibility has not been accepted. A default chosen for a visual experiment is not automatically suitable for privileged writes or new data semantics. Inspect the deployed SDK and provider configuration instead of assuming all clients receive the same decision at the same instant.

Observe the effective decision in a controlled fixture, using the permitted tenant and operation identifiers. Avoid logging every customer payload to prove flag propagation. Record the application revision, evaluated variant where available, and execution boundary. A dashboard showing the desired flag value proves less than a fresh operation demonstrating the intended admission behavior.

Test older readers against the new records

List the readers that may remain after containment: application instances, batch exports, support tools, reconciliation jobs and integrations. A reader can parse the new record successfully yet interpret it incorrectly. In the example, treating the first allocation as the whole order could omit a shipment without raising a schema error. Compatibility includes meaning, not only field presence.

Keep representative new-state fixtures before enabling the feature. Test missing and additional fields, partial workflow states, amended allocations and the transitions that an older writer might perform. A legacy writer that replaces an entire object can erase fields it never understood. Decide whether that writer must be restricted, updated or replaced during the rollback window.

Distinguish an additive field from a changed invariant. Adding an optional note may be readable by the old application. Replacing one delivery with multiple allocations changes the assumption behind fulfillment. Neither a flag nor an apparently additive database migration resolves that semantic difference automatically. Define the permitted coexistence period and the reader revisions allowed within it.

Where old readers cannot safely serve the new state, keep a compatible reader available for existing affected operations while stopping new admission. That can be safer than routing every order back to an incompatible path. The release owner must also establish how affected orders are found and who can inspect them without editing unrelated customers' data.

Choose recovery by the state that remains

Use this worksheet to decide what evidence is needed after the switch. It is a proposed review artifact, not a vendor's automatic rollback behavior. Keep the original operation and any correction linked so repeated attempts do not conceal duplicate effects.

| Remaining state | Recovery decision | Evidence required | | --- | --- | --- | | New feature request has not been admitted | Confirm the selected path refuses feature admission | Fresh request, effective flag decision and no new operation receipt | | Record uses the new representation | Keep a compatible reader or approve a transformation | Record revision, reader fixture and preserved business meaning | | Job was accepted but has not finished | Hold, continue or cancel under its operation contract | Queue identity, current effect status and authorized next action | | External action already completed | Decide a business-specific correction | Provider receipt, affected operation and correction approval | | Completion evidence is missing | Leave the operation unresolved | Evidence owner, bounded investigation and safe retry decision |

The same order can have more than one remaining state. A persisted allocation and an already-sent notification are separate effects that need linked dispositions. Do not make the rows mutually exclusive merely to simplify an incident report. Track the customer operation alongside each resource or external action it affected.

Correct the operation without erasing later work

A database restore or inverse update may overwrite a legitimate amendment made after the feature ran. Inspect the present revision and the business consequence before applying a correction. In the example, a customer may have changed the second delivery address while the supplier notification was pending. Replacing the order with its pre-feature snapshot would lose that amendment.

Microsoft's compensating-transaction guidance explains that correction can require application-specific logic, must account for concurrent changes and can itself fail. It recommends tracking progress and making repeatable steps idempotent. Use that guidance to review your chosen recovery operation, not to assume a distributed workflow can always return to its original state.

Define the correction's authority, preconditions and receipt. A proposed cancellation should name the original reservation and prove that it remains cancellable. A second attempt must recognize a previously completed correction rather than create another effect. Preserve a denied or uncertain correction as a real result, with an owner and an allowed next action.

Some consequences cannot be erased. A recipient may already have read a notification. A correcting message can explain the current situation, but it does not make the first disclosure disappear. Decide communication separately from data cleanup, using the organization's approved incident process. Avoid automated mass corrections when the evidence cannot distinguish affected operations from unaffected ones.

Rehearse the switch during unfinished work

In an isolated environment, prepare a fixture containing one ordinary order and one split order. Pause the test worker after admission but before the supplier adapter completes. Turn off new split admission, then observe fresh requests and the existing operation separately. Use an inert adapter and synthetic records; a release rehearsal must not send a real supplier instruction.

Test an older reader against the split record and compare its interpretation with the accepted fixture. Resume the worker only under the declared operation policy. Simulate a lost adapter response after an effect so the team must inspect a receipt before deciding whether to retry. This tests the uncertainty that a simple feature-toggle smoke check would miss.

Verify scope and recovery observations. Stop the exercise if it reaches a live destination, changes an unapproved record or loses the identifiers needed for reconciliation. Record already-admitted work even after the test is stopped. Restoring the fixture environment does not establish that an external test receiver forgot a previous request.

The rehearsal should produce distinct evidence for flag observation, admission containment, reader compatibility and operation settlement. If one item is missing, name the gap rather than reporting a universal rollback pass. The failure mode can change when a different worker revision or client-side cache participates, so keep those revisions with the result.

Give AI assistance the same correction boundary

An AI assistant can group affected-operation reports or propose which fields changed. Its output should link to authorized records and remain a suggestion until deterministic checks and the responsible owner accept it. A fluent explanation of a split order is not evidence that the old fulfillment worker understands it.

Do not let an assistant invent inverse transactions from a schema diff and execute them broadly. The proposed correction must account for current revisions, permissions, already-completed effects and the customer's later actions. An assistant that cannot inspect an external receipt should leave completion unknown rather than infer it from a reassuring log message.

Start the next release review with one enabled path's state inventory and one paused-worker rehearsal. Use the output reconciliation article to define business comparisons and the capability migration playbook to plan coexistence. Bring the rejected fixture and proposed correction to a platform modernization review or DevOps and SRE review. Reading these resources does not require an email address.