feat(ses,pass-style,marshal): permit Promise.any, AggregateError, cause #2042

erights · 2024-02-08T22:02:15Z

closes: #550
refs: #550 (comment) https://github.com/cosmology-tech/cosmos-kit/blob/b95e2f92585fd12d7532e846b98cd3b757c1acb8/packages/core/src/utils/endpoint.ts#L28 Agoric/agoric-sdk#7937

Description

We had previously omitted AggregateError from permits.js, effectively not permitting it as part of SES, because of concern with it not following the NativeError patterns we assume for the other errors. On further examination just now, the only non-uniformity I see are the addition of the own property errors. As an own property, it is irrelevant to the job of permits.js.

Likewise we have postponed dealing with Error cause. But it is an own property as well, and so besides the point of permits.js.

Having omitted AggregateError, we also declined to permit Promise.any since it returns an AggregateError instance. Thus, this PR simultaneously permits Promise.any.

Still need to adapt the ses console
Still need to adapt pass-style
Still need to adapt marshal
Still need to test

I am pleasantly surprised that it does not look like I need to adapt the taming of the Error constructor itself to add a cause argument to the replacement safe constructors. The replacement constructors already take and pass through ...rest arguments. But

Still need to test cause argument for the faux Error constructors, as well as a representative set of the permitted error constructors.

Security Considerations

Unlikely. But anything that permits more of the engine's surface area does in theory increase vulnerability.

Scaling Considerations

None

Documentation Considerations

If we currently document this weird exception to normal JS expectations, we can delete that explanation.

Otherwise, no docs needed since this PR just removes a surprising difference from normal JS developer expectations.

Testing Considerations

Currently, to test the handling of *Error subclasses of Error, we just test with a representative subclass such as UriError. This PR duplicates some of these tests for AggregateError.

Compatibility Considerations

We need to examine what happens if a ses that permits AggregateError talks to a ses that does not. This is mostly a marshal issue.

Some agoric-sdk compat concerns noted at #550 (comment)

The previous release of Endo seems to have some dependence on Node 12 which did not have AggregateError. This PR accommodates such early platforms reluctantly, so as not to break tests on those early platforms.

Upgrade Considerations

Nothing Breaking.

Includes *BREAKING*: in the commit message with migration instructions for any breaking change.
Updates NEWS.md for user-facing changes.

erights · 2024-02-08T22:31:10Z

@kriskowal , I'll need your help with the failure at https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042
that I do not know how to reproduce locally. (When I try naively, it locally succeeds.)

Run cd packages/ses && yarn test:platform-compatibility
  cd packages/ses && yarn test:platform-compatibility
  shell: /usr/bin/bash -e {0}
yarn run v1.[2](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:2)2.19
$ node test/package/test.cjs
/home/runner/work/endo/endo/packages/ses/dist/ses.cjs:2[3](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:3)73
  AggregateError];
  ^

ReferenceError: AggregateError is not defined
    at /home/runner/work/endo/endo/packages/ses/dist/ses.cjs:2373:3
    at Array.functors.imports (/home/runner/work/endo/endo/packages/ses/dist/ses.cjs:3721:3)
    at /home/runner/work/endo/endo/packages/ses/dist/ses.cjs:1109[4](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:5):1[5](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:6)
    at Object.<anonymous> (/home/runner/work/endo/endo/packages/ses/dist/ses.cjs:11722:3)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:8[6](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:7)3:32)
    at Function.Module._load (internal/modules/cjs/loader.js:[7](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:8)0[8](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:9):14)
    at Module.require (internal/modules/cjs/loader.js:887:1[9](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:10))
    at require (internal/modules/cjs/helpers.js:74:[18](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:19))
error Command failed with exit code 1.

packages/pass-style/src/error.js

kriskowal · 2024-02-08T23:00:21Z

@kriskowal , I'll need your help with the failure at https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042 that I do not know how to reproduce locally. (When I try naively, it locally succeeds.)

Run cd packages/ses && yarn test:platform-compatibility
  cd packages/ses && yarn test:platform-compatibility
  shell: /usr/bin/bash -e {0}
yarn run v1.[2](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:2)2.19
$ node test/package/test.cjs
/home/runner/work/endo/endo/packages/ses/dist/ses.cjs:2[3](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:3)73
  AggregateError];
  ^

ReferenceError: AggregateError is not defined
    at /home/runner/work/endo/endo/packages/ses/dist/ses.cjs:2373:3
    at Array.functors.imports (/home/runner/work/endo/endo/packages/ses/dist/ses.cjs:3721:3)
    at /home/runner/work/endo/endo/packages/ses/dist/ses.cjs:1109[4](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:5):1[5](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:6)
    at Object.<anonymous> (/home/runner/work/endo/endo/packages/ses/dist/ses.cjs:11722:3)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:8[6](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:7)3:32)
    at Function.Module._load (internal/modules/cjs/loader.js:[7](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:8)0[8](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:9):14)
    at Module.require (internal/modules/cjs/loader.js:887:1[9](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:10))
    at require (internal/modules/cjs/helpers.js:74:[18](https://github.com/endojs/endo/actions/runs/7836517151/job/21384340084?pr=2042#step:11:19))
error Command failed with exit code 1.

I tracked this down. The CI job walks back to Node.js 12, before the introduction of AggregateError. I think we can delete the platform-compatibility CI job.

erights · 2024-02-08T23:06:22Z

I think we can delete the platform-compatibility CI job.

Can I leave this to you, and proceed assuming it?

erights · 2024-02-08T23:52:06Z

I think we can delete the platform-compatibility CI job.

Can I leave this to you, and proceed assuming it?

@kriskowal did. Done.

erights · 2024-02-11T04:12:38Z

Several places we use an ErrorConstructor generically, assuming its signature is uniform across all error constructors.

This uniform signature had not included cause. Now it should.
AggregateError may be passed as such an error constructor. But when such a generic error constructor parameter is used to make an error constructor, we need to adjust to the different parameters of the AggregateError constructor.

erights · 2024-02-21T16:54:00Z

Seeing #2093 , I assume we'll do a new endo release soon, and then try again to do an agoric-sdk sync based on that. Given that, I'd really like to get this approved, merged, and into that upcoming endo release if possible.

From the review comments above, the outstanding issue seems to be explicit testing under XS. Reviewers, although I agree we need this in general, here's why I think we no longer need this specifically for this case:

As mentioned previously, the success of DO NOT MERGE: test "current" agoric-sdk with "current" endo master Agoric/agoric-sdk#7937 with

#endo-branch: markm-550-any-w-aggregate-error

seems to indicate that ses at least initializes successfully in XS and does not cause any breakage in existing agoric-sdk CI tests. OTOH, the failure of the previous endo release despite #endo-branch testing of agoric-sdk indicates that #endo-branch is doing less compat testing than we thought. I don't know where the line is. Advise or clarification appreciated.

With the changes mentioned at feat(ses,pass-style,marshal): permit Promise.any, AggregateError, cause #2042 (comment) above, endo CI establishes that this PR now adapts to platforms such as Node 12 that lack AggregateError or were prior to introduction of AggregateError into the language standard. Presumably, this dependence on version of the language was the main reason to be more concerned about cross-platform testing for this PR than for other PRs.

Further, even after we have test262-like tests running under XS, this still doesn't give us adequate tooling to run this PR's tests under XS, since this PR's tests are written in ava. Do we have plans to be able to run our ava tests under XS? I am not aware of any. (Having raised this, I think we should. But not immediately. And I'm not sure how hard it would actually be.)

So, reviewers, what do you think of reviewing this PR for possible merging now, before we have the tooling to explicitly run the tests under XS.

kriskowal · 2024-02-21T17:02:01Z

Seeing #2093 , I assume we'll do a new endo release soon, and then try again to do an agoric-sdk sync based on that. Given that, I'd really like to get this approved, merged, and into that upcoming endo release if possible.

From the review comments above, the outstanding issue seems to be explicit testing under XS. Reviewers, although I agree we need this in general, here's why I think we no longer need this specifically for this case:

As mentioned previously, the success of DO NOT MERGE: test "current" agoric-sdk with "current" endo master Agoric/agoric-sdk#7937 with
#endo-branch: markm-550-any-w-aggregate-error
seems to indicate that ses at least initializes successfully in XS and does not cause any breakage in existing agoric-sdk CI tests. OTOH, the failure of the previous endo release despite #endo-branch testing of agoric-sdk indicates that #endo-branch is doing less compat testing than we thought. I don't know where the line is. Advise or clarification appreciated.

With the changes mentioned at feat(ses,pass-style,marshal): permit Promise.any, AggregateError, cause #2042 (comment) above, endo CI establishes that this PR now adapts to platforms such as Node 12 that lack AggregateError or were prior to introduction of AggregateError into the language standard. Presumably, this dependence on version of the language was the main reason to be more concerned about cross-platform testing for this PR than for other PRs.

Further, even after we have test262-like tests running under XS, this still doesn't give us adequate tooling to run this PR's tests under XS, since this PR's tests are written in ava. Do we have plans to be able to run our ava tests under XS? I am not aware of any. (Having raised this, I think we should. But not immediately. And I'm not sure how hard it would actually be.)

So, reviewers, what do you think of reviewing this PR for possible merging now, before we have the tooling to explicitly run the tests under XS.

We now have a test262 runner that spans XS on master but it is not integrated into CI. #1847

We do have plans in motion to build SES 262 tests. I do not have a clear idea of how to build 262 tests that target modules. It probably would involve bundling.

dckc · 2024-02-21T17:04:08Z

reviewers, what do you think of reviewing this PR for possible merging now, before we have the tooling to explicitly run the tests under XS.

I don't object. never did. But nor do I feel confident in approving. I hope another reviewer can do that.

kriskowal

I’m confident enough that there are no backward-compatibility surprises to merge and find out in Agoric SDK sync CI. @gibson042’s blessing on the Smallcaps change would be great since that’s the one area where my confidence is poorly substantiated.

A thought experiment I couldn’t complete on my own:

What is the current behavior for marshaling AggregateError or Error cause? Were the properties stripped or the message rejected?
If existing programs could send AggregateError, can existing programs receive an AggregateError and handle the appearance of new properties?
If existing programs could not send AggregateError, I see no compatibility concerns.

packages/common/NEWS.md

packages/errors/NEWS.md

packages/marshal/NEWS.md

packages/marshal/test/test-marshal-capdata.js

packages/pass-style/NEWS.md

packages/pass-style/src/passStyleOf.js

packages/ses/NEWS.md

erights · 2024-02-21T19:51:43Z

I’m confident enough that there are no backward-compatibility surprises to merge and find out in Agoric SDK sync CI. @gibson042’s blessing on the Smallcaps change would be great since that’s the one area where my confidence is poorly substantiated.

The additional test cases in test-marshal-capdata.js and test-marshal-smallcaps.js are exactly parallel.

A thought experiment I couldn’t complete on my own:

What is the current behavior for marshaling AggregateError or Error cause? Were the properties stripped or the message rejected?

Prior to this PR, as AggregateError is passed as an Error. error.cause and error.errors as well as any additional properties are not sent.

With this PR, AggregateError is passed as AggregateError. However, it is still the case that error.cause and error.errors as well as any additional properties are not sent, since we cannot yet assume that all counter-parties have been upgraded to at least #2052 (already in the previous endo release) that enables them to tolerate receiving extra properties.

If existing programs could send AggregateError, can existing programs receive an AggregateError and handle the appearance of new properties?

If existing programs could not send AggregateError, I see no compatibility concerns.

Prior to this PR, a program attempting to send an AggregateError would actually send an Error. So I think this falls into your "I see no compatibility concerns" case.

gibson042

A few test comments, but I agree with @erights's assessment.

gibson042 · 2024-02-21T20:21:46Z

packages/marshal/test/test-marshal-capdata.js

+  if (typeof AggregateError === 'undefined') {
+    t.pass('skip test on platforms prior to AggregateError');
+    return;
+  }


This seems too disruptive; we should only skip the narrow subset of test logic that won't work as expected.

packages/marshal/test/test-marshal-capdata.js

gibson042 · 2024-02-21T22:06:03Z

packages/pass-style/src/error.js

+  passStyleOfRecur,
+  check = undefined,
+) => {
+  const reject = !!check && (details => check(false, details));


See #2097 for a more concise pattern.

Ref #2042 Ref #550

#9275) closes: #XXXX refs: endojs/endo#2042 ## Description Starting at endojs/endo#2042 endo fully supports the real `AggregateError` constructor, so there is no longer any need for the `makeAggregateError` workaround. 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 old `makeAggregateError` was emulating it using a direct instance of `Error`, 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 genuine `AggregateError`, 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 --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

@gibson042

closes: #XXXX refs: endojs/endo#2096 endojs/endo#2042 ## Description Deleting @agoric/base-zone's implementation of `isPassable` completes the migration of `isPassable` from @agoric/base-zone to @endo/pass-style explained in endojs/endo#2096 and started in endojs/endo#2042 The remaining issue explained in endojs/endo#2096 , changing how `isPassable` is implemented, remains to be done in @endo/pass-style. But this need no longer concern us here since that difference will now be encapsulated from us. ### Security Considerations None ### Scaling Considerations We know that `passStyleOf` remains a performance hotspot that needs attention. This PR does not affect that at all. But I'll note that the remaining suggested change from endojs/endo#2096 --- to implement `isPassable` and `passStyleOf` in terms of a more expressive internal function parameterized by a checker --- might make this performance issue worse. Just something to keep in mind as we tune `passStyleOf`. Attn @gibson042 ### Documentation Considerations none ### Testing Considerations none ### Upgrade Considerations As of this PR, @agoric/base-zone also no longer exports `isPassable`, potentially breaking importers outside agoric-sdk until they are modified to import it from @endo/pass-style as well. This PR does take care of all such import sites within agoric-sdk. If this turns out to be a problem in practice, this PR could be changed to have @agoric/base-zone reexport the `isPassable` it imports from @endo/pass-style, but deprecate that reexport, leaving it to future work to change those old import sites outside agoric-sdk. --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

mhofman · 2024-06-12T22:26:19Z

Talking about XS testing, we definitely should, and in particular we should test under the version of XS used by agoric-sdk, which currently does not support AggregateError

erights self-assigned this Feb 8, 2024

erights commented Feb 8, 2024

View reviewed changes

packages/pass-style/src/error.js Outdated Show resolved Hide resolved

erights changed the title ~~feat(ses): permit Promise.any, AggregateError~~ feat(ses,pass-style,marshal): permit Promise.any, AggregateError Feb 8, 2024

erights changed the title ~~feat(ses,pass-style,marshal): permit Promise.any, AggregateError~~ feat(ses,pass-style,marshal): permit Promise.any, AggregateError, cause Feb 8, 2024

erights requested review from samsiegart and kriskowal February 8, 2024 23:17

erights force-pushed the markm-550-any-w-aggregate-error branch 8 times, most recently from b9802aa to 0c98c96 Compare February 10, 2024 23:29

erights force-pushed the markm-550-any-w-aggregate-error branch 8 times, most recently from ca5b2a4 to 2987499 Compare February 11, 2024 07:04

erights mentioned this pull request Feb 11, 2024

feat(marshal): tolerate extra error props #2052

Merged

2 tasks

erights force-pushed the markm-550-any-w-aggregate-error branch from 2987499 to f508532 Compare February 11, 2024 18:53

erights changed the base branch from master to markm-tolerate-extra-error-props February 11, 2024 18:53

erights force-pushed the markm-550-any-w-aggregate-error branch 2 times, most recently from bcb917d to 3d9354d Compare February 21, 2024 14:27

erights requested review from turadg, samsiegart and dckc February 21, 2024 16:54

erights force-pushed the markm-550-any-w-aggregate-error branch from 3d9354d to 947710e Compare February 21, 2024 17:22

kriskowal approved these changes Feb 21, 2024

View reviewed changes

erights mentioned this pull request Feb 21, 2024

Implement an isPassable that does not rely on try/catch. #2096

Open

gibson042 approved these changes Feb 21, 2024

View reviewed changes

gibson042 reviewed Feb 21, 2024

View reviewed changes

kriskowal force-pushed the markm-550-any-w-aggregate-error branch 3 times, most recently from ca51656 to 45fafbc Compare February 22, 2024 01:06

erights added 2 commits February 21, 2024 17:09

feat(ses): permit Promise.any, AggregateError

6a8c4d8

fix(ses,pass-style,marshal): tolerate platforms prior to AggregateError

5762dd4

kriskowal force-pushed the markm-550-any-w-aggregate-error branch from 45fafbc to 5762dd4 Compare February 22, 2024 01:09

kriskowal merged commit 18fb8c0 into master Feb 22, 2024
14 checks passed

kriskowal deleted the markm-550-any-w-aggregate-error branch February 22, 2024 01:17

gibson042 added a commit that referenced this pull request Feb 22, 2024

test(marshal,ses): Prefer test.skip over conditional early return

9e354f8

Ref #2042 Ref #550

gibson042 mentioned this pull request Feb 22, 2024

test(marshal,ses): Prefer test.skip over conditional early return #2099

Open

gibson042 added a commit that referenced this pull request Feb 22, 2024

test(marshal,ses): Prefer test.skip over conditional early return

a98519a

Ref #2042 Ref #550

This was referenced Apr 14, 2024

fix(base-zone,zone): import isPassable from @endo/pass-style Agoric/agoric-sdk#9230

Merged

refactor(internal): deprecate makeAggregateError in favor of Aggregat… Agoric/agoric-sdk#9275

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(ses,pass-style,marshal): permit Promise.any, AggregateError, cause #2042

feat(ses,pass-style,marshal): permit Promise.any, AggregateError, cause #2042

erights commented Feb 8, 2024 •

edited

Loading

erights commented Feb 8, 2024

kriskowal commented Feb 8, 2024

erights commented Feb 8, 2024

erights commented Feb 8, 2024

erights commented Feb 11, 2024 •

edited

Loading

erights commented Feb 21, 2024 •

edited

Loading

kriskowal commented Feb 21, 2024

dckc commented Feb 21, 2024

kriskowal left a comment

erights commented Feb 21, 2024

gibson042 left a comment

gibson042 Feb 21, 2024

gibson042 Feb 21, 2024

mhofman commented Jun 12, 2024

feat(ses,pass-style,marshal): permit Promise.any, AggregateError, cause #2042

feat(ses,pass-style,marshal): permit Promise.any, AggregateError, cause #2042

Conversation

erights commented Feb 8, 2024 • edited Loading

Description

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Compatibility Considerations

Upgrade Considerations

erights commented Feb 8, 2024

kriskowal commented Feb 8, 2024

erights commented Feb 8, 2024

erights commented Feb 8, 2024

erights commented Feb 11, 2024 • edited Loading

erights commented Feb 21, 2024 • edited Loading

kriskowal commented Feb 21, 2024

dckc commented Feb 21, 2024

kriskowal left a comment

Choose a reason for hiding this comment

erights commented Feb 21, 2024

gibson042 left a comment

Choose a reason for hiding this comment

gibson042 Feb 21, 2024

Choose a reason for hiding this comment

gibson042 Feb 21, 2024

Choose a reason for hiding this comment

mhofman commented Jun 12, 2024

erights commented Feb 8, 2024 •

edited

Loading

erights commented Feb 11, 2024 •

edited

Loading

erights commented Feb 21, 2024 •

edited

Loading