Distillation

Date: Sep 16, 2026

• 🟡 (15:42) User supplied the next continuation of the recall-aware Responses streaming implementation, approximately lines 10748-11803, covering recall settlement, continuation normalization, follow-up protocol failures, transactional commit/rollback handling, retry baselines, final response emission, transaction readiness, principal-reader cleanup, and principal retry outcomes.
• 🔴 (15:42) The directive “Always accumulate into the internal state for postResponse.” appears again at approximately line 11050, bringing the supplied implementation’s observed occurrences to at least 3.
• 🟡 (15:42) Recall-principal failure handling throws the exact error new Error("recall principal returned response.failed").
• 🟡 (15:42) Recall processing tracks transactionalBytes, calls settleRecall, and appends executed.commit to pendingCommits when present.
• 🟡 (15:42) Continuation handling can classify a failure as "follow_up_protocol" and tracks continuation recall traffic with continuationRecallBytes.
• 🟡 (15:42) Continuation events are processed through normalizeCodexEvent using contNormalizationState; continuation recall items are identified via contRecallIndices, and tool items are compared against RECALL_TOOL_NAME.
• 🟡 (15:42) Continuation error handling checks SSEStreamTransportError and can rethrow or wrap errors as RecallContinuationFailure.
• 🟡 (15:42) Continuation retry state uses continuationRetryBaseline; when no explicit category exists, the fallback failure category is "unexpected".
• 🟡 (15:42) Transaction finalization guards against duplicate settlement with transactionSettled; on success it invokes opts.onTransactionReady?.(transaction).
• 🟡 (15:42) Principal-stream cleanup sets principalReader = null, and later control flow derives an outcome from shouldRetryPrincipal.