A device edits a record while disconnected and the far side changes the same record - what must the case pin down about the resolution?

When a record is edited on a device that has no connection and the same record is changed on the far side before the device returns, the product must decide something. A case about that moment is worth writing only if it pins down what was decided, in a way that survives the next change to the machinery underneath. Most weak versions of this case fail on one of two counts: the divergence happens by luck rather than by construction, or the expected result was copied from the behaviour that was observed the first time it ran. ## Manufacture the divergence; never wait for it The case owns both branches, so it should create both explicitly: 1. Seed the record through a service interface with a value the case chose, and let the device synchronise so it holds that value. 2. Take the link away with a control the run owns, and confirm it is down. 3. Edit the field on the device. That is the local branch. 4. Change the same field on the far side through a service interface. That is the remote branch. 5. Restore the link, and wait on an observable condition - outstanding work reaches zero, an idle signal is raised - rather than a fixed pause. Every step is under the case's control, so the same divergence is reproduced on every run. A case that hopes two edits collide because a background process happened to be slow is measuring scheduling, not resolution. ## Four things the case must pin down - **The surviving value.** Which of the two the product ends up holding, stated in advance. - **The fate of the losing edit.** Discarded, preserved alongside as a second version, or held for the user to reconcile - all three are legitimate designs and they are not interchangeable. - **Agreement.** The device and the far side must end up on the same value; read both, because one of them alone hides half the failures. - **What the user is told.** If a version of their work was dropped, silence is a design decision someone has to own, and the case should assert whatever was chosen. ## The written rule is the oracle The expected value comes from a rule the team recorded, not from running the application and writing down the result. That distinction is the whole professional content of the question: recording current behaviour produces a case that defends a bug as loyally as it defends a feature. | Recorded rule | Expected surviving value | What the case asserts about the loser | | --- | --- | --- | | Latest change by a single clock wins | The later of the two, by that clock | Gone, and the user is notified | | The far side always wins | The remote value | Local edit preserved as a copy | | Per-field merge where fields differ | Both changes present | Nothing was lost; assert each field | | The user resolves it | Neither, until a choice is made | Both candidates offered on screen | If nobody can tell you which row applies, that is the finding. Produce the divergence by hand, show the outcomes the product could plausibly have, and make someone choose. The choice becomes the expectation; the case then defends it against regression forever after. ## Determinism when clocks or arrival order decide Where the rule leans on time, the case must control the inputs the rule reads rather than racing real time. Complete the local edit before the link is restored. Apply the far-side change at a moment the case picks. Where the values are supplied by the caller, seed them; where they are stamped on arrival, order the arrivals. The test of a good conflict case is simple: run it twenty times and it gives the same verdict twenty times. If it flips, it is not telling you about resolution - it is telling you which branch got there first today, and that is not a property anyone agreed to. ## Why a case that only checks for a crash is close to worthless The failure everyone actually fears is silent data loss, and losing an edit crashes nothing. The screen looks fine, no error is raised, and the user finds out days later that the note they typed on a train never existed. An assertion that the application is still running is satisfied equally by correct merging and by throwing the work away, which is why the surviving value, the loser's fate, the agreement of both sides and the notification are the four assertions worth having. ## What this case does not own It does not design the resolution strategy, the delivery mechanism, or the scheduling that decides when reconciliation runs. Those are architecture questions with their own home, and a behavioural case that encodes their internals breaks every time they are tuned. This case treats the decision as a stated contract and proves the product honours it - which is precisely what lets the machinery beneath be rewritten with confidence.