refactor(internal): deprecate makeAggregateError in favor of Aggregat… #9275
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
Deploying agoric-sdk with
|
| Latest commit: |
84f938d
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://6242ef3d.agoric-sdk.pages.dev |
| Branch Preview URL: | https://markm-deprecate-makeaggregat.agoric-sdk.pages.dev |
turadg
approved these changes
Apr 22, 2024
There was a problem hiding this comment.
Reviewers, please let me know if you'd prefer that I delete makeAggregateError, as I'd be happy to.
Yes, please. As you point out, only agoric-sdk should import from this package. If removing makeAggregateError does break any imports it will be valuable to find out.
erights
force-pushed
the
markm-deprecate-makeAggregateError
branch
from
ebabe0d
to
92a19a3
Compare
Done |
This was referenced Jun 14, 2024
mergify bot
pushed a commit
that referenced
this pull request
Jun 15, 2024
…9508) closes: #9504 ## Description While #9275 switched to a global `AggregrateError` constructor, it was unclear if that was safe because that global is not currently available in xsnap. Instead of reverting, this PR moves the "shared" internal helpers that used an `AggregateError` to the `node` folder, to make it clear they should only be used in that environment. All usages of these helpers were already in Node only. All other usages of `AggregateError` were audited to confirm they only happened on Node as well. ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations None ### Testing Considerations We're unfortunately lacking coverage of some code under xsnap, Open to ideas on how to improve testing here It would also be nice somehow to make sure the `node` folders do no end up imported in bundled code. Maybe having a pseudo `import 'node:process'` could work? @kriskowal ### Upgrade Considerations None
mhofman
added a commit
that referenced
this pull request
Jun 20, 2024
…9508) closes: #9504 ## Description While #9275 switched to a global `AggregrateError` constructor, it was unclear if that was safe because that global is not currently available in xsnap. Instead of reverting, this PR moves the "shared" internal helpers that used an `AggregateError` to the `node` folder, to make it clear they should only be used in that environment. All usages of these helpers were already in Node only. All other usages of `AggregateError` were audited to confirm they only happened on Node as well. ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations None ### Testing Considerations We're unfortunately lacking coverage of some code under xsnap, Open to ideas on how to improve testing here It would also be nice somehow to make sure the `node` folders do no end up imported in bundled code. Maybe having a pseudo `import 'node:process'` could work? @kriskowal ### Upgrade Considerations None
mhofman
added a commit
that referenced
this pull request
Jun 22, 2024
…9508) closes: #9504 ## Description While #9275 switched to a global `AggregrateError` constructor, it was unclear if that was safe because that global is not currently available in xsnap. Instead of reverting, this PR moves the "shared" internal helpers that used an `AggregateError` to the `node` folder, to make it clear they should only be used in that environment. All usages of these helpers were already in Node only. All other usages of `AggregateError` were audited to confirm they only happened on Node as well. ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations None ### Testing Considerations We're unfortunately lacking coverage of some code under xsnap, Open to ideas on how to improve testing here It would also be nice somehow to make sure the `node` folders do no end up imported in bundled code. Maybe having a pseudo `import 'node:process'` could work? @kriskowal ### Upgrade Considerations None
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.
closes: #XXXX
refs: endojs/endo#2042
Description
Starting at endojs/endo#2042 endo fully supports the real
AggregateErrorconstructor, so there is no longer any need for themakeAggregateErrorworkaround. The @agoric/internal packages should not be imported by anything outside the agoric-sdk repo, so technically I could remove it in this same PR. As a conservative don't-break-things, I still export it as deprecated.Even after upgrading to an endo supporting
AggregateError, the oldmakeAggregateErrorwas emulating it using a direct instance ofError, so this is in theory not a pure refactor. But I would be flabbergasted if any code came to depend on this not being a genuineAggregateError, in which case this change is a pure refactor.Reviewers, please let me know if you'd prefer that I delete
makeAggregateError, as I'd be happy to.Security Considerations
none
Scaling Considerations
none
Documentation Considerations
none
Testing Considerations
none
Upgrade Considerations
none