[psteinroe]

Fixes the wait deadline and timeout findings from the review: C11 (O3-02), C12 (O5-03), C23 (O5-04 plus the memoization gap R4 found), O4-08, and owner decision D5c (durations).

C11: result waits accepted outcomes that settled after their deadline

Root cause. _private_resolve_result_waits stored an outcome without looking at the wait's expires_at. On top of that, when the waiter resumed, _private_register_event_race went over every branch again, stored the outcome of any execution that had settled by then, and picked a winner before it checked the timeout. So an execution that settled after the deadline, but before an unpolled waiter resumed, still won.

Fix.

• _private_resolve_result_waits joins each wait to its subscription and stores the outcome only if expires_at is null or expires_at >= now. Every path that ends an execution calls it at the moment the outcome settles, so the check compares the deadline with the outcome's terminal time, not with when the waiter resumes. The bound is inclusive, the same as dispatch uses for events (created_at <= expires_at).
• _private_register_event_race registers an execution branch only on its first call, meaning branches that have neither a stored step nor a subscription. A branch that already has a subscription gets its outcome from the path that ends the execution, which checks the deadline. On the first call, an execution that has already settled still resolves at once. The unknown-execution check also covers only new branches, so an awaited execution that settles late and is then removed by retention gives a timeout, not "not found".

C12: waitForAny with no open branch ignored its timeout

Root cause. A race keeps its deadline only on its branch subscriptions. A race with no branches, or only branches that an earlier race closed, has no subscription to hold the deadline. So every resume computed a new deadline and suspended again, forever, without using up attempts.

Decision: fail fast. If a race has no winner and no open subscription, _private_register_event_race raises waitForAny "<stepKey>" has no open branch. This is always a programming error. Honouring the timeout instead would need race state stored separately, only to always return { key: "timeout" }. Documented in the ctx.waitForAny() reference.

C23: a caught invokeAndWait timeout broke later child calls and was not memoized

Root cause. invokeAndWait treated "the claimed snapshot has waiting_on_execution_id" as "this call timed out". So a second invokeAndWait in the same attempt threw the same timeout without starting its child. The timeout itself was also never stored: once clearWaitingState had cleared the waiting fields, a later replay invoked the timed-out child a second time and waited on it again.

Fix. Following R4's note, clearing the snapshot alone is not enough; the timeout has to be stored.

• The step of an invokeAndWait now stores {status: 'completed', result} (settlement) or {status: 'timed_out'}. The raw child result could not be told apart from a timeout marker.
• clearWaitingState stores the timeout under the parent's waiting_step_key in the same statement that cancels the child and clears the wait. It is fenced by the claim token and returns whether it still held the claim. If not, the attempt hangs up as suspended instead of throwing.
• invokeAndWait treats a missing result as a timeout only when the claim's waiting_step_key is its own key. A claim keeps that key only while the execution waits on a child. Any other key starts the child.

O4-08: conductor.waitForResult timeout during a blocked read

getExecution now cancels its query (postgres.js query.cancel()) when the signal aborts. waitForResult rejects with the abort reason (a TimeoutError for the timeout) whether the read fails because of the cancel or returns after the deadline. Cancelling on abort applies only to this read; settlement still runs under the worker's aborted signal, as O4-08 asked.

D5c: durations

ctx.sleep(), BatchTaskContext.sleep(), the ctx.invokeAndWait() timeout and the conductor.waitForResult() timeout now take a DurationInput (numbers are milliseconds, or a string such as "30s"), parsed with parseDuration(). The event and result waits already took one. Config fields whose name carries the unit (timeoutMs, pollIntervalMs, batch.timeoutMs, throttle.seconds, removeOnComplete.days) are unchanged.

Behaviour changes

• timeout: 0 means zero, never infinity. Before, ctx.invokeAndWait(..., { timeout: 0 }) waited forever, and conductor.waitForResult(id, { timeout: 0 }) had no timeout. Now the first times out at once and cancels the child, and the second rejects with a TimeoutError at once. Omit timeout to wait indefinitely.
• Negative, non-finite or malformed durations now throw (parseDuration). Before, they were passed to SQL or setTimeout.
• A caught invokeAndWait timeout is thrown again on every replay, instead of invoking the child again.
• waitForAny with no open branch throws instead of waiting.
• Stored invokeAndWait steps change shape ({status, result}). The migration is edited in place, as the project does during active development. A database with child waits in flight from an older build would read their stored result wrongly.

Tests

tests/integration/wait-deadlines.test.ts brings in the R3/R4 reproductions with their barriers and fake time unchanged:

• C11 (3 cases: completion, cancellation, and a mixed event/execution race): the waiter's orchestrator stops after it suspends, fake time moves past the deadline, then the awaited execution settles and a new orchestrator resumes the waiter. All 3 fail on main and pass now.
• C12 (no branches, and only a branch an earlier race closed): the repro asserted "settles", which suited either fix. It now asserts the fail-fast error, with maxAttempts: 1.
• C23 (both tests): one change from the repro. A memoized timeout is thrown again on each replay, so errors holds one entry per run of the handler, and the sleeping flag (also true for a completed parent) is no longer asserted.
• O4-08: a second connection holds an access exclusive lock on the executions table. waitForResult(id, { timeout: 100 }) must reject with TimeoutError while the lock is still held, and the connection is usable afterwards. Without the change the read stays blocked.
• D5c: invokeAndWait with timeout: 0 times out at once and cancels the child. conductor.waitForResult with timeout: 0 rejects. ctx.sleep("nap", "1m") reschedules by one minute.

The existing test for a first registration against an execution that has already settled still passes.

just lint, just format, pnpm typecheck and the full pnpm test pass. One existing test (wait-for-result.test.ts, "a pending child cancelled when its parent's wait times out") set waiting_on_execution_id by hand without waiting_step_key, a state settlement never produces; it now sets both.

Hot paths

• In settlement, only the projection of parent_steps_all changes (it wraps the result in jsonb_build_object); the plan does not change.
• _private_resolve_result_waits runs only when a settled execution has waiters. Its new join is a lookup on the unique (execution_id, step_key) index.
• _private_register_event_race and clearWaitingState run once per wait, not per claim or settlement.

Follow-ups (out of scope)

• invokeAndWait deadlines in settlement. A child that completes after the parent's deadline, but before the parent resumes, still delivers its result (completed_parents does not compare parent.run_at with now). A child that fails late still fails the parent through the cascade. Applying the same terminal-time rule there is a change to settlement and deserves its own PR.
• conductor.waitForResult logs the cancelled read at error level through DatabaseClient.query() ("canceling statement due to user request"). It is harmless, but noisy if callers often time out against a blocked database.