The Graph Changed While the Approval Was Waiting

Botie prepared a change for P8 when its revision was three. While a person reviewed that proposal, another technician updated P8 to revision four. Applying the old plan without checking would overwrite a decision made with newer information.

We need to separate preparing a change, approving it and committing it against current state. A snapshot check can reveal an obviously stale request, but only the database transaction can protect the final write from concurrent changes.

An approved request can become stale before it reaches the executor.

A proposal should identify its target, intended change, caller and the state it was based on. The approval should be tied to that proposal rather than a general reusable “yes.”

Our exercise deliberately selects eligible target IDs only. It does not apply status changes, validate arbitrary payloads or claim to perform an atomic update. Those responsibilities belong to the eventual authorised executor.

A useful preflight result says which requests need further execution checks.

Only boolean true counts as approval in the example. A string such as “true” is not the same typed value. Compare expected_revision with the target’s current snapshot revision, and exclude missing targets.

A stale request should return to review or be recalculated according to policy. Quietly changing expected_revision to the latest number would remove the protection the field was meant to provide.

Approval and freshness are independent conditions.

request={'expected_revision':3}
asset={'revision':4}
print(request['expected_revision']==asset['revision'])

False

Between a browser preflight and a server write, another update can occur. Use a database-supported transaction and locking or conditional-update strategy whose isolation semantics have been checked for the deployed database.

A read in one transaction followed by an unconditional write in another is not optimistic concurrency control. Even a predicate and write in one statement need the engine’s documented concurrent-update semantics; do not assume a snapshot comparison creates a lock.

The workshop intentionally stops before commit and cannot establish transaction isolation.

The external example demonstrates the simpler unit: update one uniquely identified asset inside an application-managed transaction, then verify exactly one target was returned before committing. It does not implement the revision conflict policy by itself.

Use an authorised driver session, a parameterised reviewed query and explicit rollback when the matched target count violates the contract. Do not execute arbitrary Cypher generated by a user or model as the writer role.

Application validation, authorisation and concurrency control remain required around this query.

MATCH (a:Asset {id:$asset})
SET a.status=$status
RETURN a.id AS updated

A driver-managed transaction function may be invoked again after a transient failure. Sending an email, charging a service or issuing a physical maintenance action inside that retried function can repeat the effect even if the database transaction rolled back.

Keep external actions out of automatically retried database callbacks. Where an action must follow a commit, use a durable outbox or another explicit delivery design with idempotency keys and reconciliation. A database rollback cannot undo an email already sent.

Exactly-once business effects require more than calling MERGE or retrying a transaction.

MERGE matches or creates the supplied pattern. Match stable identity separately from mutable fields and back required uniqueness with constraints. A replayed logical request should have a stable idempotency identity if its outcome must be reconciled.

DELETE of a node with relationships and DETACH DELETE have different consequences. Broad deletion patterns can remove connected history. Preview the exact target identities and use least-privilege permissions; the lesson’s preflight does not authorise a deletion.

Read the write pattern as a description of everything it may affect.

The challenge checks explicit approval, known target and matching integer revision. It retains each eligible target ID once for this report. Real executors still need per-request identity, payload validation and conflict handling when several proposals target the same node.

That limited output makes the lesson’s claim testable: the records qualify for further execution checks under this snapshot. It never says those changes have been safely committed.

Keep the displayed result at the same level of authority as the mechanism that produced it.