AggregateError serialization is standard track

[ddbeck]

Summary

Note: This PR is somewhat incomplete. Please read fully before merging.

AggregateError's serialization is potentially standard track, depending on how you look at it. I'm opening this to settle the question. After some head scratching, I'm proposing that AggregateError's serialization be marked as standard track, with all implementations being marked as partial, but I'm open to other views.

Test results and supporting details

The HTML spec is somewhat odd when it comes to the serialization of errors. Note step 17 in section 2.7.3 StructuredSerializeInternal ( value, forStorage [ , memory ] ).

There are two noteworthy things here:

• It describes handling for any object with [[ErrorData]], which includes AggregateError but not AggregateError specifically (as it does for other error types).
• It also says that "User agents should attach a serialized representation of any interesting accompanying data […]" with a note that says the "interesting" data isn't yet specified.

Taken together, the compat data tells a maybe odd story, that AggregateError is not serializable (it is though some ambiguously "interesting" information is, depending on your perspective, being lost) and that Firefox's behavior is non-standard (which it is, when it comes to the cloned object's type).

whatwg/html#5749 looks to settle this more comprehensively, but it hasn't merged yet.

To thread the needle, I suggest marking AggregateError's serialization as standard track (shown in the diff now), with all implementations being marked as partial (to be done), but I'm open to other views.

Related issues

• Handle AggregateError in structured data cloning whatwg/html#5716
• Expand JS error serialization whatwg/html#5749
• FF103 Errors are serializable (support structuredClone) #17008
• ECMAScript discouraged/legacy feature web-platform-dx/web-features#2564

[caugner]

Yes, AggregateError seems to be serializable per the HTML Standard: The referenced step 17 applies to AggregateError, because it has an [[ErrorData]] internal slot (whose value is undefined, which is not a platform object).

@ddbeck Why would you consider the Firefox implementation as partial? Because the serialize representation is missing the [[Type]] field (provided that the current note is accurate), or because it has additional fields?

As for Chrome and Safari, did you research their current behavior regarding serialization of AggregateError? Or does "all implementations" only refer to Firefox?

[ddbeck]

Why would you consider the Firefox implementation as partial? Because the serialize representation is missing the [[Type]] field (provided that the current note is accurate), or because it has additional fields?

As for Chrome and Safari, did you research their current behavior regarding serialization of AggregateError? Or does "all implementations" only refer to Firefox?

Firefox's non-standard behavior is to serialize to an AggregateError with errors information, where the spec says it should be an Error. That is, in Firefox:

structuredClone(new AggregateError([new Error("some error")], "Hello")).name
→ AggregateError
structuredClone(new AggregateError([new Error("some error")], "Hello")).errors
→ /* an array of Errors */

So Firefox is doing the right thing with respect to step 17.6 ("User agents should attach a serialized representation of any interesting accompanying data which are not yet specified […] to serialized"), but the wrong thing with respect to step 17.2 ("If name is not one of […], then set name to 'Error'").

Where Safari and Chrome do as the spec (currently) says with respect to the name, but loses the interesting errors:

structuredClone(new AggregateError([new Error("some error")], "Hello")).name
→ Error
structuredClone(new AggregateError([new Error("some error")], "Hello")).errors
→ undefined

Basically, I don't think anyone is doing this correctly with respect to the specification (though Firefox's implementation is plainly more useful).

[caugner]

Thanks for the clarifications, @ddbeck!

So currently the BCD data for AggregateError states no support in Chrome and Safari, and we should fix that as part of this PR, adding notes about how they deviate from the spec.

Next up, we should fix the Firefox note to be a bit more clear, and explain the deviation from the specification.

When compared to other cases where we decide between partial and "just a note", I feel like partial is a bit harsh here, as all browsers, especially Firefox, seem to have a usable implementation with minor limitations. At the same time, marking the implementations as partial could increase the chances of these limitations to be fixed.

@Elchi3 What do you think?

[caugner]

Can we add a link to this text fragment:

"spec_url": "https://html.spec.whatwg.org/multipage/structured-data.html#:~:text=if%20value%20has%20an%20%5B%5Berrordata%5D%5D%20internal%20slot",

[Elchi3]

I'm not a big fan of these text fragment URLs as I can't validate them (#23958) but I will not stay in the way if we think they are adding value.

[caugner]

In our October 29, 2024 meeting we reached consensus to use text fragments where anchors aren't available.

In this case, we could link to the section instead, but it wouldn't be as straight-forward.

[caugner]

In my opinion, any text fragment spec link is better than none.

[Elchi3]

I think this can land as is. Seems like specification work is a bit behind unfortunately

[caugner]

PS: I mentioned the spec text fragment in the commit message.