Choose a compatible return

Video transcript

1. 0:00–0:06

   Name the recovery action • Rollback, disablement and repair do different work. • Change the running version • Compatible rollback • Avoid a faulty path • Feature disablement • Introduce another change • Forward repair • Data restore is a separate decision; inspect failure and current state

   Three intended effects connect to distinct recovery choices: changing the running code to a compatible prior version, disabling a faulty feature path while keeping the application, and introducing a forward repair. Data restore is a separate decision. Choose from the actual failure and current state, with a named authority; missing observations are not evidence that a destructive action is appropriate. No live recovery action is performed.

2. 0:06–0:12

   Check the state that exists • New values can close an older return path. • Stored ticket state • C · activated writer • awaiting_customer • A reads open / closed only: new value blocks this return • Invented ticket example · verify every reader and retained message

   In the article invented support-ticket example, original A understands open and closed. Activated C can write awaiting_customer. A native status token moves from C into shared stored state and stays there; the incompatibility warning then highlights. A cannot be assumed safe once the new value exists. Preparation must include screens, workers, exports and retained-message consumers, not only one application instance. Turning a feature off does not erase existing values or queued messages.

3. 0:12–0:18

   Prepare a compatible version • In the example, C can return to prepared B. • A: original values • B: reads new values • C: writes new values • Return candidate: B • B · reads both; writes original values • Existing new values stay intact

   The complete reviewed A/B/C diagram shows the return from C to prepared B with A blocked. This assumes B correctly handles original and new values in reads and user actions, preserves existing new values, and creates only original statuses. B is the candidate return under that tested model, not a universal rollback guarantee. Keep the prepared version available for the agreed period and test actual schema, application and message compatibility.

4. 0:18–0:24

   Account for completed effects • Reverting code does not unsend a message. • Code rollback • Stored data • Completed actions • Reconcile • Running version · C • Running version · B • T17 · new status remains • M17 · message remains sent

   The code-layer diagram is paired with native running-version labels: C disappears before B takes its place. Illustrative T17 retains its new status and M17 remains sent. No record or external effect vanishes. Data restoration requires product-specific supported points, access, validation and reconnection, plus reconciliation of valid later activity. A code return does not recall an email, shipment or external charge; compensation needs authority. A timed-out external action can be uncertain, so blind retries can repeat effects.

5. 0:24–0:30

   Rehearse the decision • Record authority, checks and recovery evidence. • User task + permissions • Record actual evidence • Workers + retained messages • Records + external references • Named operator + access + decision rule + acceptance • Business target ≠ rehearsal observation ≠ guarantee

   User tasks and permissions, workers and retained messages, then current records and external references connect to actual evidence to record. Rehearse the forward change and return after new writes in controlled representative conditions, including mixed versions where relevant. Name the operator, access, decision and exclusions, acceptance and observation period; keep a reachable versioned runbook and incident communication. Business RTO/RPO targets, observed rehearsal results and explicit contractual commitments remain different. Review existing hosting/recovery inclusions before scoping extra work; a deployment tool alone cannot solve application incompatibility.