PR #1592: retry error boundary review

Authority and scope

The reviewed PR head was 1bf6a0bc47eb0021a926994b82af27cc326403f6. The primary executable owner is packages/offline-transactions/tests/transaction-settlement-oracle.property.test.ts. The README promises that shouldRetry receives the named mutation function's same Error instance. Public manual outbox removal also acknowledges deletion while a provider can still be running. If that provider then fails, its caller must settle from that failure and a retry cannot recreate the removed row.

The reviewer separately observed that a hook fault loses the provider error. The maintainer chose the exact hook error as the caller-facing and stored error; the provider error remains in the warning. The serialized format stores name, message, and stack, so arbitrary error prototypes and custom fields are not restored after an offline executor restart. The documented invalid Promise result is observed for rejection; arbitrary third-party thenables are outside the current contract and Node-hosted oracle evidence.

Oracle-first experiments

The cross-realm history throws a node:vm Error with status = 401 from the real named mutation function. The hook must receive that object by identity, persist a first retry record, and later fulfill a public commit() after a successful second attempt. A local Error and a plain status-bearing object are neighboring existing controls: the former keeps identity, and the latter is converted before the hook. This case fails on the reviewed executor at the hook-identity assertion: it receives a wrapper with no status.

The removal history holds the public provider call, acknowledges either removeFromOutbox or clearOutbox, then releases a network failure under the default retry decision or a 401 under a true hook answer. Before release, the row is absent and both caller promises are pending. After release, both must reject with the provider Error, the row must stay absent, and a later peer must fulfill in the same executor. On the reviewed executor, both removeFromOutbox cases fail the caller-outcome assertion with pending promises. The two clearOutbox cases time out at the caller-settlement checkpoint because that API clears the scheduler's running count before the provider returns; those timeouts are progress failures, not assertion kills. The existing successful-provider removal witness is the nearby fulfillment control. A narrower missing-row branch in the retry-persistence catch repairs the reported failure; unrelated storage errors still stop the batch.

On the repaired working tree, all 60 settlement-oracle cases passed. The new cross-realm case, four removal cases, and the existing successful-provider removal cases passed in focused runs. The package typecheck and edited-file ESLint passed. The prior Preview CI failure was a 404 from the external preview publisher; rerunning only Preview succeeded, and the current published head's other CI jobs passed. These CI results predate the follow-up source commit.

Guide audit

Requirement	Evidence or limit
ORC-001 authority	The README's same-instance hook rule and acknowledged public removal supply the two laws; provider and storage are controlled.
ORC-002 independence	Expected identity, rejection, absence, and peer progress come from those public contracts, not the executor's classifier or scheduler.
ORC-003 literate responsibilities	The oracle opening states the laws and limits. Local prose gives the legal histories, real public driver, observations, and checkpoints beside each case.
ORC-004 grammar controls	The fixed removal matrix reconstructs two APIs crossed with default network and hook 401 retry. Each axis changes the reached path. A removal after retry persistence begins and an unacknowledged removal are excluded. The cross-realm Error is distinguished from a local Error and a plain object.
ORC-005 path and observation	Public commit(), isPersisted, peekOutbox, provider calls, and later peer settlement are observed at held-provider, acknowledged-removal, rejection, and later-peer cuts.
ORC-006 calibration	The reviewed production code fails the cross-realm identity assertion and both removeFromOutbox caller assertions. clearOutbox reports two classified timeouts. The repair passes the same cases.
ORC-007 campaigns	The new histories are fixed cases, so the campaign trigger does not apply. The existing generated retry decision property still runs fixed-seed and seedless campaigns.
ORC-008 model state	No reference-model state was added or merged.
ORC-009 vocabulary	Outbox row, named mutation function, optimistic state, and offline executor restart follow the glossary.
ORC-010 cleanup	Held providers are released and pending callers are rejected in finally; cleanup keeps the primary failure distinct.
ORC-011 second formulation	The same-instance law is checked by direct object identity and by its status-based retry consequence. The removal law has the success-after-removal neighboring history.
ORC-012 review evidence	This record identifies the reviewed head, exact RED checkpoints, GREEN runs, and limits. The repaired revision is the commit containing this record.
ORC-013 boundary witness	A 401 Error from another realm distinguishes conversion from identity; default network and overridden 401 retry distinguish the missing-row consequence.
ORC-014 provider handoff	No live server or native-storage claim is made. The fake adapter and controlled provider establish only the executor boundary.

The bounded removal witness covers deletion acknowledged before the provider settles. A manual removal overlapping the read and write inside outbox.update could resurrect a row; that interleaving has not been exercised. The settlement owner needs a controlled witness and an atomicity decision for it. The coverage map records this open boundary. A browser-host receiving witness would be needed to claim cross-realm behavior through an actual iframe or worker rather than node:vm.