Skip to content
C.W.K.
Stream
Lesson 02 of 04 · published

Queued Can Change; Taken Cannot

~12 min · state-machine, mutation, take, immutability

Level 0Cold Vessel
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

Queued Can Change; Taken Cannot

Queued work still belongs to intake. The requester may fix a typo, replace an attachment, change a brain hint, or withdraw the delegation entirely. Those mutations are legitimate because no executor has accepted the premises yet.

Take is the transfer point. A live session claims the work, and the package becomes evidence about what that session was authorized to do. Editing notes or attachments afterward would create two histories: what the author actually saw and what the database now says they saw.

The safest API makes the rule structural. Mutation endpoints check status and return a conflict once the delegation is taken, landed, or abandoned. The UI disables controls as a convenience, but the engine is the authority; stale tabs and direct clients cannot bypass the transition.

Correction after take requires a new recorded event. Depending on product policy, abandon and requeue, or create a superseding delegation linked to the first. The original package remains intact so reviewers can explain why work stopped.

The Race at Take

A status check and mutation must happen under one writer transaction. If edit reads queued while take commits concurrently, only one operation may win. The loser receives the new state and chooses a visible next action.

Test this with two clients, not only sequential calls. The invariant is not “edit usually happens first”; it is “no successful mutation occurs after a successful take,” regardless of scheduling.

Take is the boundary between drafting and evidence. A queued order may be corrected because nobody owns its execution yet. Once claimed, edits would change the instructions underneath an active author, so correction must become an explicit replacement, abandon, or new delegation.

Code

Make mutation conditional on lifecycle state·python
def edit_material(delegation: dict, replacement: str) -> None:
    if delegation["status"] != "queued":
        raise RuntimeError(f"material frozen at {delegation['status']}")
    delegation["material"] = replacement

d = {"status": "queued", "material": "v1"}
edit_material(d, "v2")
d["status"] = "taken"
try:
    edit_material(d, "v3")
except RuntimeError as exc:
    print(exc)
assert d["material"] == "v2"

External links

Exercise

Write a concurrent test where edit and take race. Assert that exactly one wins and that a successful take leaves the original material hash stable.
Hint
Use a barrier so both operations start from the queued state.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.