feat(ocap-kernel): name the failing vat when a subcluster vat fails to launch#975
Draft
grypez wants to merge 7 commits into
Draft
feat(ocap-kernel): name the failing vat when a subcluster vat fails to launch#975grypez wants to merge 7 commits into
grypez wants to merge 7 commits into
Conversation
…o launch When a vat fails to launch (e.g. its `buildRootObject` throws, surfacing from `VatHandle.make`), `VatManager.launchVat` now re-throws attributing the failure to the specific vat by both its kernel id and its `ClusterConfig` name, e.g. `Failed to launch vat v3 (bob)`, preserving the original error as the cause. Previously the underlying error propagated verbatim with no indication of which subcluster vat failed. Also adds regression tests for #572 covering clean bootstrap-failure propagation and rollback in `SubclusterManager`. Refs: #564, #572 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A failed vat launch is now re-thrown by `VatManager.launchVat` as `Failed to launch vat <id> (<name>)` with the original error preserved on `cause`. Update the integration assertions that previously matched the detail (excluded global, `buildRootObject`/global-scope throw) in the top-level message to search the `cause` chain instead, via a shared `causeChainMessage` helper. The bootstrap-throw path is unchanged (it does not flow through `launchVat`). Refs: #564, #572 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A vat launch that fails at the `initVat` RPC boundary (e.g. an excluded
global, invalid params) surfaces as a plain JSON-RPC error object
(`{ code, message, data }`) rather than an `Error`, which `VatManager.launchVat`
then preserves on `cause`. The previous helper gated its walk on
`instanceof Error`, so it stopped at such a cause and lost the detail.
Walk anything with a `message`/`cause` and fold in `data`, so the
launch-failure assertions find the reason regardless of the cause's shape.
Add direct unit coverage for the helper.
Refs: #564, #572
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||
…e helper Assert launch failures with `toMatchObject`: the top-level message is the `Failed to launch vat <id> (<name>)` attribution wrapper and the reason lives on `cause.message`. `toMatchObject` matches both a real `Error` cause (the delivery-error path) and a plain JSON-RPC error object (the initVat RPC boundary), so the `causeChainMessage` helper and its unit test are no longer needed and are removed. Refs: #564, #572 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #564
Closes #572
Explanation
When a vat in a subcluster fails to launch — most notably when its
buildRootObjectthrows, surfacing fromVatHandle.makeasFailed to initialize vat <vatId>: ...— the error previously propagated through#launchVatsForSubclusterverbatim, giving no indication of whichClusterConfigvat failed (the internal kernel id alone is meaningless to someone reading a cluster config).VatManager.launchVatnow wrapsrunVatand, on failure, re-throws attributing the failure to the specific vat by both its kernel id and itsClusterConfigname, preserving the original error as thecause:This is the only seam where both the minted
vatIdand thevatNameare in scope.SubclusterManager.launchSubclusteralready rolls back the subcluster and rethrows on the failure, so the named error surfaces to the caller.This addresses the "throw an error describing which vats failed to
buildRootObject" ask from #564. It also confirms (via new regression tests) that the original cryptic symptom —SES_UNHANDLED_REJECTION: no record matching key 'queue.run.3'(#572) — no longer occurs: the bootstrap subroutines reject cleanly and roll back.Changes
VatManager.launchVat: attribute launch failures to<vatId> (<vatName>), with the original error ascause; omit the parenthetical when launched without a name.VatManager.test.tscovers the attribution, cause preservation, and no-name cases.SubclusterManager.test.tsadds#572regression tests for clean bootstrap-failure propagation and rollback.References
#launchVatsForSubcluster#564 (primary ask), refs feat(ocap-kernel): Make #launchVatsForSubcluster throw when its subroutines cause an uncaught promise rejection #572Checklist
🤖 Generated with Claude Code