Skip to content
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

structuredClone Serializing a non-serializable platform object succeeds #55120

Closed
RedYetiDev opened this issue Sep 25, 2024 · 8 comments
Closed
Labels
confirmed-bug Issues with confirmed bugs. web-standards Issues and PRs related to Web APIs

Comments

@RedYetiDev
Copy link
Member

In Node.js, the following snippet succeeds, whereas, in the browser, it throws a DataCloneError:

structuredClone(new Response());

This is causing the following WPT to fail:

structuredCloneBatteryOfTests.push({
  description: 'Serializing a non-serializable platform object fails',
  async f(runner, t) {
    const request = new Response();
    await promise_rejects_dom(
      t,
      "DataCloneError",
      runner.structuredClone(request)
    );
  }
});
@KhafraDev
Copy link
Member

A JavaScript value value is a platform object if Type(value) is Object and if value has a [[PrimaryInterface]] internal slot.

The primary interface of a platform object is the value of the object’s [[PrimaryInterface]] internal slot, which is the most-derived interface that it implements.

Request's webidl declaration does not extend anything, therefore it's a platform object.

Hopefully this may help someone.

@KhafraDev
Copy link
Member

@nodejs/web-standards @joyeecheung

@RedYetiDev RedYetiDev added confirmed-bug Issues with confirmed bugs. web-standards Issues and PRs related to Web APIs labels Sep 26, 2024
@sOnU1002

This comment was marked as spam.

@jazelly
Copy link
Member

jazelly commented Oct 4, 2024

I am a bit curious how undici will adopt this to address this issue. Don't get me wrong, it will address the issue, but the process will probably be like:

  1. release that PR
  2. land a new commit on undici to mark all classes uncloneable, which might be semver-major
  3. node waits for that undici release and bump the deps

The whole thing could be dragged a bit long, and I am thinking should we consider the fast win with a TODO to drop it once the above process is settled?

@KhafraDev
Copy link
Member

It won't be a semver-major issue, changes that are made for spec-compatibility are usually considered bug fixes. This bug was only caught in a WPT - the behavior is far too niche to justify the performance overhead of constructing every Response, Request, FormData, Headers, etc.

@RedYetiDev
Copy link
Member Author

@jazelly just confirming the Unidici PR fixed this, and it'll be good-to-go when the next version of Undici releases?

@jazelly
Copy link
Member

jazelly commented Oct 18, 2024

Yes, once that's released and bumped in node, this should be resolved.

@RedYetiDev
Copy link
Member Author

I'm gonna close this, as while the latest Node.js doesn't have the Undici needed, it's no longer actionable as an issue. Thx!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed-bug Issues with confirmed bugs. web-standards Issues and PRs related to Web APIs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants