feat(pass-style): generalize passable errors, throwables #2223
Conversation
This file contains 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
erights
force-pushed
the
markm-to-throwable
branch
2 times, most recently
from
1402c8a
to
dd4b963
Compare
1 task
erights
added a commit
that referenced
this pull request
May 6, 2024
closes: #XXXX refs: #2223 ## Description Modest step towards #2223 , - bringing all the intended safety: the exo boundary only throws throwables, and that `callWhen` async exo methods only reject with throwable reasons. - but with less flexibility: the definition of passable errors and throwables is narrower than it need be. ### Security Considerations This is one of three necessary steps towards having the exo boundaries become the new intravat defensive security boundary, rather than treating every object boundary as a potential defensive security boundary. The rationale for this step is that the throw-control-path is too hard for reviewers to pay full attention to, so we wish to prevent caps from leaking over the exo boundary via the throw path. (E prevented caps from escaping via throws in general, but we're not in a position to be able to enforce that in general within Hardened JS.) The other two steps are - Converting uses of `Far` for making far objects into making exos. - Addressing the leakage of promise settlements across exo boundaries due to the inability to synchronously enforce such a constraint on a promise passed through the boundary. ### Scaling Considerations Given that the exceptional pathways (throws and rejects) are only used for low frequency exceptional conditions, or at least exceptional conditions whose speed we don't care about, making this slow path a tiny bit slower should be inconsequential. Indeed, I expect the overall impact to be unmeasurable. (But we won't know until we measure!) ### Documentation Considerations This restriction on what can be throws across the exo boundary (or for exo async `callWhen` methods, what can be used as a rejection reason) needs to be documented. But it should not affect any normal code, and so documents an edge case. ### Testing Considerations tests included ### Compatibility Considerations If there are currently any throws or rejects that violate these constraints (likely) where other code depends on these violations (unlikely), then we have a compat problem. ### Upgrade Considerations None. - ~[ ] Includes `*BREAKING*:` in the commit message with migration instructions for any breaking change.~ - [x] Updates `NEWS.md` for user-facing changes.
erights
force-pushed
the
markm-to-throwable
branch
from
76c3c58
to
d06c83b
Compare
Merged
erights
force-pushed
the
markm-to-throwable
branch
4 times, most recently
from
0d49be1
to
b450373
Compare
erights
force-pushed
the
markm-to-throwable
branch
3 times, most recently
from
55ee7c5
to
6d1363a
Compare
erights
force-pushed
the
markm-to-throwable
branch
2 times, most recently
from
2e2ee98
to
4163fa8
Compare
This was referenced Aug 27, 2024
erights
force-pushed
the
markm-to-throwable
branch
from
4163fa8
to
5c5287a
Compare
erights
changed the base branch from
master
to
markm-repair-arraybuffer-transfer-2
erights
force-pushed
the
markm-to-throwable
branch
from
5c5287a
to
d32a490
Compare
erights
changed the base branch from
markm-repair-arraybuffer-transfer-2
to
markm-anticipate-disposal
erights
force-pushed
the
markm-to-throwable
branch
from
d32a490
to
409a62f
Compare
erights
force-pushed
the
markm-anticipate-disposal
branch
from
7a908f6
to
611ea5b
Compare
erights
force-pushed
the
markm-to-throwable
branch
from
409a62f
to
05c5887
Compare
erights
force-pushed
the
markm-anticipate-disposal
branch
from
611ea5b
to
62895a4
Compare
erights
force-pushed
the
markm-to-throwable
branch
from
05c5887
to
e36bdfc
Compare
erights
force-pushed
the
markm-anticipate-disposal
branch
from
a0ac6a1
to
2901427
Compare
erights
force-pushed
the
markm-to-throwable
branch
from
e36bdfc
to
63e87ec
Compare
|
We should consider only allowing a passable error as a throwable so that we maintain the ability to reconstitute distributed stack traces. Only the top level needs to be a passable error, nested values can be any copy data or passable error. |
|
See also Agoric/agoric-sdk#10375 |
erights
force-pushed
the
markm-to-throwable
branch
from
8ab11e5
to
c11a861
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Just placeholder for now. Not yet expected to work or almost work.
closes: #XXXX
refs: #XXXX
Description
Security Considerations
Scaling Considerations
Documentation Considerations
Testing Considerations
Compatibility Considerations
Upgrade Considerations
*BREAKING*:in the commit message with migration instructions for any breaking change.NEWS.mdfor user-facing changes.