Durable expiry and cancellation of human validation

The project server persists a wait at a human.approve or human.review checkpoint. Decisions, expiry and cancellation retain their meaning after a restart. Source approval constraints reuse this lifecycle; it does not introduce a general scheduler.

Lifecycle

A source timeout_ms sets the occurrence deadline in UTC. Without it, the server defaults to 24 hours after request creation. Server time is authoritative and restart does not extend the deadline. A decision is accepted only before it. At the exact deadline, expiry wins; backdating a client decision does not make it valid.

Resolution	Behavior
Timely decision	Persist it; execution resumes only after an explicit resume request.
Expiry	Follow the explicit on expired branch, if declared; otherwise stop with expired. The approved continuation is not entered.
Cancellation	An awaiting_human interaction operation can be cancelled before the deadline if no decision has already won.

Cancellation at or after the deadline becomes expiry. Cancellation does not undo effects already applied before the human checkpoint.

Restart and correlation

Before accepting requests, the server reloads waits, resolves overdue expiry and completes interrupted terminalization. A stored resolution cannot be replaced by restart or a second request. If the server is down at the deadline, expiry is observed at its next start. No background timer runs while it is down.

Human trace events use authority_ref = approval_ref and a related_ref such as decision:pending or the actual terminal outcome. The durable record, not the trace, arbitrates the resolution. Repairing a persisted terminal projection does not re-execute the runtime or duplicate its correlated event.

Invalid state preventing startup terminalization stops the server from listening. Later terminalization failures retain the acquired resolution and are retried every 30 seconds. Reading or refreshing the request does not bypass that delay.

Capacity and boundary

• One local, single-process owner of the state files.
• Capacity defaults to 100 waits, configurable up to 10,000 with --max-pending-approvals; parallel waits retain their distinct occurrences.
• At most 100 interaction sessions; nonterminal sessions are not evicted.
• Capacity is reserved before a new run that can pause; exhaustion refuses it before the runtime or handler.
• One next wake-up, no distributed scheduler.
• Cancellation uses the existing interaction operation, not a separate direct sandbox cancellation route.

This mechanism does not provide reminders, reassignment, automatic purging of terminal records or distributed exactly-once execution. See Human validation and Durable resume.

Approvals inside parallel groups

One checkpoint may preserve several branch continuations. The server presents the current request and releases it only through its exact decision, not through a group-wide approval. After resume, another occurrence may request its own decision. Completed branches and budgets survive restart. The single-current-wait limit per run therefore does not mean one approval for every branch. See Human validation.

An explicit on expired branch may request another approval. Every path in that branch must end with give or stop, without falling through to the approved continuation. The server stores the new request and marks the old one superseded. See the roles and deadlines tutorial.