-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: use @endo/errors #9513
Conversation
Deploying agoric-sdk with Cloudflare Pages
|
} | ||
if (VERBOSE) { | ||
console.log('REJECTED at top of event loop', reason); | ||
} | ||
}; | ||
|
||
const wrapFunction = | ||
(func, sendingError, X) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why were we passing X
around rather than using a module-global one?
d74c5bf
to
a0ab697
Compare
a0ab697
to
76b43af
Compare
Closes: #XXXX Refs: Agoric/agoric-sdk#9515 Agoric/agoric-sdk#9514 ## Description Addresses Agoric/agoric-sdk#9515 as applied to endo, by doing for endo what Agoric/agoric-sdk#9514 does for agoric-sdk To address Agoric/agoric-sdk#5672 for endo , we should change all applicable uses of `assert` to obtain `assert` by importing it from the `@endo/errors` package. However, attempts to do so ran into the symptoms reported at Agoric/agoric-sdk#9515 for the reasons reported there -- accidentally using the imported `assert` as the endowment for the global `assert` of new Compartments. This PR prepares the ground for these fixes to Agoric/agoric-sdk#5672 for endo by unambiguously endowing with the original unstructured `globalThis.assert`, which will remain the correct endowment even when other uses of `assert` have migrated to the one imported from `@endo/errors`. By itself, this PR, preceding those fixes to Agoric/agoric-sdk#5672 for endo , is not actually fixing a bug in the sense of a behavioral change. Reviewers, let me know if you think this PR should be labeled a "refactor" because of this. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations anyone gathering endowments for a new compartment should be aware of this issue, and be sure to use `globalThis.assert` as the `assert` endowment. Fortunately, this will only be of concern to advanced developers. ### Testing Considerations Since this PR doesn't actually cause any behavioral change, it cannot be tested in place. Rather, its test will be whether #2324 still passes CI once rebased on this PR. ***Update***: #2324 is now passing CI well enough to consider this PR (#2323) to be adequately tested. ### Compatibility Considerations The point. This PR itself only prepares the ground for the equivalent of Agoric/agoric-sdk#9513 for endo. By itself it has no other effect, and so no other compat issues. ### Upgrade Considerations none
00619c6
to
89f599b
Compare
Staged on #2323 Closes: #XXXX Refs: Agoric/agoric-sdk#5672 Agoric/agoric-sdk#9513 ## Description Does for endo what Agoric/agoric-sdk#9513 does for agoric-sdk --- importing `assert` from @endo/errors --- when it can do so without causing dependency cycles. For the remaining packages that would cause dependency cycles, just move them towards more modern assert conventions while still using the unstructured global `assert` ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations We should document `assert` only as imported from @endo/errors, since our users will not generally contribute code within endo's internal dependency cycles. ### Testing Considerations The CI run on this PR also serves to test #2323, since that one, by itself, does not cause a behavioral change. It's purpose is to enable this PR not to hit the problem described at Agoric/agoric-sdk#9515 ### Compatibility Considerations none ### Upgrade Considerations none
closes: #9515 refs: #5672 #8332 #9513 endojs/endo#2323 ## Description To address #5672 , we should change all uses of `assert` to obtain `assert` by importing it from the `@endo/errors` package. However, attempts to do so (#8332 #9513) ran into the symptoms reported at #9515 for the reasons reported there -- accidentally using the imported `assert` as the endowment for the global `assert` of new Compartments. This PR prepares the ground for these fixes to #5672 by unambiguously endowing with the original unstructured `globalThis.assert`, which will remain the correct endowment even when other uses of `assert` have migrated to the one imported from `@endo/errors`. By itself, this PR, preceding those fixes to #5672 , is not actually fixing a bug in the sense of a behavioral change. Reviewers, let me know if you think this PR should be labeled a "refactor" because of this. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations anyone gathering endowments for a new compartment should be aware of this issue, and be sure to use `globalThis.assert` as the `assert` endowment. Fortunately, this will only be of concern to advanced developers. ### Testing Considerations Since this PR doesn't actually cause any behavioral change, it cannot be tested in place. Rather, its test will be whether #9513 still passes CI once rebased on this PR. ***Update***: #9513 is now passing CI well enough to consider this PR (#9514) to be adequately tested. ### Upgrade Considerations This PR by itself does not have any dependence on @endo/errors existing, and so should be compatible even when linked against fairly ancient versions of endo.
closes: #9515 refs: #5672 #8332 #9513 endojs/endo#2323 ## Description To address #5672 , we should change all uses of `assert` to obtain `assert` by importing it from the `@endo/errors` package. However, attempts to do so (#8332 #9513) ran into the symptoms reported at #9515 for the reasons reported there -- accidentally using the imported `assert` as the endowment for the global `assert` of new Compartments. This PR prepares the ground for these fixes to #5672 by unambiguously endowing with the original unstructured `globalThis.assert`, which will remain the correct endowment even when other uses of `assert` have migrated to the one imported from `@endo/errors`. By itself, this PR, preceding those fixes to #5672 , is not actually fixing a bug in the sense of a behavioral change. Reviewers, let me know if you think this PR should be labeled a "refactor" because of this. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations anyone gathering endowments for a new compartment should be aware of this issue, and be sure to use `globalThis.assert` as the `assert` endowment. Fortunately, this will only be of concern to advanced developers. ### Testing Considerations Since this PR doesn't actually cause any behavioral change, it cannot be tested in place. Rather, its test will be whether #9513 still passes CI once rebased on this PR. ***Update***: #9513 is now passing CI well enough to consider this PR (#9514) to be adequately tested. ### Upgrade Considerations This PR by itself does not have any dependence on @endo/errors existing, and so should be compatible even when linked against fairly ancient versions of endo.
closes: #9515 refs: #5672 #8332 #9513 endojs/endo#2323 ## Description To address #5672 , we should change all uses of `assert` to obtain `assert` by importing it from the `@endo/errors` package. However, attempts to do so (#8332 #9513) ran into the symptoms reported at #9515 for the reasons reported there -- accidentally using the imported `assert` as the endowment for the global `assert` of new Compartments. This PR prepares the ground for these fixes to #5672 by unambiguously endowing with the original unstructured `globalThis.assert`, which will remain the correct endowment even when other uses of `assert` have migrated to the one imported from `@endo/errors`. By itself, this PR, preceding those fixes to #5672 , is not actually fixing a bug in the sense of a behavioral change. Reviewers, let me know if you think this PR should be labeled a "refactor" because of this. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations anyone gathering endowments for a new compartment should be aware of this issue, and be sure to use `globalThis.assert` as the `assert` endowment. Fortunately, this will only be of concern to advanced developers. ### Testing Considerations Since this PR doesn't actually cause any behavioral change, it cannot be tested in place. Rather, its test will be whether #9513 still passes CI once rebased on this PR. ***Update***: #9513 is now passing CI well enough to consider this PR (#9514) to be adequately tested. ### Upgrade Considerations This PR by itself does not have any dependence on @endo/errors existing, and so should be compatible even when linked against fairly ancient versions of endo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is in my review queue. It has many conflicts with master so I'm requesting a rebase before reviewing.
Done. PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With a couple nits. Comments marked “Aside” do not need to be addressed in this change. I hope to never review this again :-)
The SES version in new or upgraded vats after upgrade-16 is now in sync with master, and will be forward as we release from a master branch. Since #9514 was included in upgrade-16, and that the ZCF bundle is updated by that release, I believe it is safe for this to land because any new or upgraded Zoe contract will find the correct |
Staged on #9514
closes: #5672
refs: #8332 #9512 #9514
Some description text below copied from #8332
Description
Use the new
@endo/errors
and retire@agoric/assert
.This deletes the
@agoric/assert
package but doesn't so far as to deprecate it in NPM.Fixes #5672 -- migrating all applicable uses of
assert
to import it from @endo/errors and use that one. This is a fresh attempt to do over what #8332 and #9512 tried to do.Note that this is staged on #9514 which addresses #9515 -- ensuring that the
assert
used in endowing a new compartment is not theassert
imported from @endo/errors but is rather the originalglobalThis.assert
. For the agoric-sdk repo, that should be the only needed use ofassert
that should not be changed to use the one imported from @endo/errors.Security Considerations
Relies more directly on Endo, instead of through the
assert
package.Scaling Considerations
none
Documentation Considerations
we should generally document @endo/errors as the only source of
assert
. However, we still need to call out the special case of Compartment endowments covered by #9514 and #9515Testing Considerations
If CI passes here, it not only tests the correctness of this PR, but also of #9514, since #9514 by itself does not cause any testable changes. It is only to enable the changes in this PR to work.
Upgrade Considerations
TBD.
@endo/errors
may require a newer SES than the vats have in their global env (for theassert
global).