fix(ocap-kernel): leave a settled result promise alone on delivery failure

[sirtimid]

A delivery can fail after the endpoint has already settled the message's result promise: a vat resolves the result and then loses its stream, or the stream dies mid-delivery and retiring the vat rejects every promise it was deciding — this one included, its decider having been set just before the delivery.

#deliverSend's catch rejected the result unconditionally, and resolving a settled promise is a Fail. So the kernel threw from inside the very catch that was handling the delivery's failure, the throw escaped the crank, and the run loop died naming the promise rather than the dead worker.

#rejectResultIfPending reads the promise's state first and leaves a settled one alone, logging that it did: the caller then gets the endpoint's answer instead of DELIVERY_FAILED, and the error line above it is the only other trace of either outcome.

This is one PR in the split of #1021–#1023 into single-defect changes.

Changes

• KernelRouter#rejectResultIfPending replaces the direct resolvePromises call in the delivery-failure catch, returning early when the result is not unresolved.
• The early return logs the result's kref, the endpoint and the state it is in.
• @metamask/ocap-kernel changelog entry under Fixed.

Testing

KernelRouter.result-promise.test.ts is new, because KernelRouter.test.ts mocks resolvePromises and so cannot see a second resolution of one promise. It runs a real nodejs SQLite :memory: store and a real KernelQueue through the run loop's crank — same savepoint name, same collectGarbage and reference count audit at the end, no catch, so a throw escapes as it does in the real loop.

The it.each over an endpoint that fulfils and one that rejects is the regression guard: with the production hunk reverted, both fail with "kp1" was already resolved escaping KernelRouter.deliver. The positive case, rejects it once the delivery reports failure, stays green under that mutation and fails under a guard that always returns early.

Full @metamask/ocap-kernel suite green locally (2534 tests); eslint, constraints and changelog:validate clean.

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches kernel message delivery and promise settlement on failure paths; incorrect handling could still crash the run loop or mis-report errors to callers.

Overview
Fixes a run-loop crash when message delivery fails after the vat has already settled the message’s result promise (e.g. resolve then stream loss).

KernelRouter’s delivery-failure handler no longer unconditionally rejects the result with DELIVERY_FAILED. New private helper #rejectResultIfPending reads the kernel promise state first: only unresolved results get DELIVERY_FAILED; if the endpoint already fulfilled or rejected it, that outcome is kept and an error is logged instead of calling resolvePromises again (which would Fail and escape the catch).

Adds KernelRouter.result-promise.test.ts with a real SQLite store and queue (existing router tests mock resolvePromises). Unit test setup defaults getKernelPromise to { state: 'unresolved' }. Changelog updated under Fixed.

^{Reviewed by Cursor Bugbot for commit b7c95ea. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	73.05% ⬆️ +0.01%	9791 / 13403
🔵	Statements	72.9% ⬆️ +0.01%	9955 / 13655
🔵	Functions	73.61% ⬆️ +0.01%	2302 / 3127
🔵	Branches	67.3% ⬆️ +0.01%	4025 / 5980

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/ocap-kernel/src/KernelRouter.ts	94.4% ⬆️ +0.20%	81.15% ⬆️ +0.56%	100% 🟰 ±0%	94.4% ⬆️ +0.20%	110, 173, 190, 292, 345, 405, 423, 426

Generated in workflow #4861 for commit b7c95ea by the Vitest Coverage Report Action

[FUDCo]

Nice catch.

[FUDCo]

Eventually it converges. It does eventually converge, right?