Where does unfinished work live?

Keep the request after the worker stops

Case D-41 belongs to one verified customer account and one delivery-date request. Save its requested date, current status, last checked order version, outstanding question, next check time, and responsible person. Retain references to permitted evidence rather than copying every message into the case. The team needs access and retention rules for that record too.

A new attempt must not create a new customer request or a fresh operation for an uncertain change. Keep those identities separate. When the intended change itself changes, prepare a new proposal and obtain whatever approval it needs rather than reusing an old yes.

This design makes the support lead responsible for D-41 and a named backup responsible during absence. They need to see why it is waiting, which system or person must answer, and when to follow up. Assigning an agent to the job does not supply that operating responsibility.

Write what may happen next

Use statuses that distinguish the next safe action. Here, the normal path waits for the order source, prepares a proposal, waits for review, and only then becomes ready for an authorized update. Record each status change with its reason and the version of the case it changed.

Waiting is not permission to wait forever. If AP-9 expires while the case is queued, return it to review. If the source changes, prepare current evidence and invalidate the old proposal or approval as required. If the customer no longer has access, stop the affected work. A status labeled ready cannot override any of those checks.

Workers and cancellation can arrive together. The application's state store needs a conditional transition: let one worker move the expected case version from ready to applying only if it has not been cancelled or claimed. That coordinates who may start the work. It does not make saving the case and changing the order one indivisible update. The case could say applying after the order update failed, or the order could change before the worker saved its confirmation. The order system still needs its own version check as part of the update and protection against applying the same operation twice. If those capabilities are absent, keep the first service review-only.

Now suppose D-41-a1 claims Applying and stops reporting. Its lease, a time-limited claim on the work, expires. A coordinator considers replacement attempt D-41-a2. But D-41-a1 may only be paused: it could wake later and still submit DATE-41-1. Claim expiry proves neither that the old worker stopped nor that the order was left unchanged. Hold D-41 and reconcile the same operation before deciding whether another attempt may apply it. If submission might have begun and the source cannot settle the result, keep Effect unknown.

Safe takeover needs an additional check where the order change is accepted. The receiving system, or a trusted action service that controls the update, must reject stale ownership in the same indivisible step that applies the change. It must also enforce current permission, the exact unexpired approval, the expected order version, and slot availability there. Checking a claim and then pausing before a separate update would leave time for that claim or approval to expire. Replacing the worker must not reopen that gap.

A local lock only coordinates workers that obey it. A fencing token is a numbered ownership marker sent with an attempt so the receiver can reject an older owner. Merely saving that number in the case, or passing it to an order system that does not check it, cannot stop D-41-a1 from changing the order. Verify how the receiving boundary makes the current ownership check inseparable from the effect. If it cannot do that, keep continuation supervised and the service review-only; do not let a replacement blindly retry the write.

A cancellation request cannot undo an unknown change

Suppose the authorized worker submits DATE-41-1 and the network times out. Then the customer asks to cancel. The order may already have changed. Save the cancellation request, but do not mark D-41 cancelled or start a replacement operation merely because the worker has stopped. Keep the result unknown and ask the responsible person to reconcile it.

Use permitted source-system evidence to find DATE-41-1 and confirm the order, resulting version, and intended state. A matching Friday date alone is insufficient if someone else could have made that change. If the source proves the operation happened, record it; reversing it would be a new, separately authorized action. If the source cannot settle the result, keep the case with its owner and next check time rather than reporting either success or cancellation.

A delayed lookup can return not found while the order system is still processing the submission or before its search record catches up. That answer alone does not prove DATE-41-1 had no effect. Keep the hold until the system's permitted evidence can establish what happened. If the customer cancels or AP-9 expires during the hold, record that change and block any new application under the old approval. Continue only the permitted investigation; a later worker cannot turn the held case into fresh permission to write.

Hand the unfinished case to another person

Before relying on this design, stop a test worker while a case waits for its source, then while it waits for approval. Ask another person to locate the case and explain the next permitted action without the original chat. Also test expired approval, two workers claiming the same case, cancellation racing with application, and an unavailable source after a timeout. The worksheet records expected outcomes; these exercises have not been run here.

For the missing-worker case, stop D-41-a1 after it claims Applying but before it submits, then after it submits but before it saves the result. Consider two replacement workers and let the original worker resume late. Check that stale workers cannot change the order, only one current worker can proceed, and every attempt retains DATE-41-1. Also try cancellation or approval expiry during the hold and a delayed not found response. Inspect actual order-system changes and its ownership and approval checks; a saved Applying label cannot supply that evidence.

Choose the store and worker around these failure tests. In the test environment, restore a backup of the saved case records after an order has changed. Those restored records may be older than the change in the order system. Check that the replacement worker finds the pending operation and checks it against the source before resuming; it must not repeat the change because its restored records lack a confirmation. Test access, retention, and data migrations on the actual service too. Writing a JSON file or saving chat history does not establish production durability or show that it can safely continue unattended.