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

compress/gzip: "TypeError: performance.markResourceTiming is not a function" on js/wasm when using Node 18 #57516

Closed
dmitshur opened this issue Dec 29, 2022 · 1 comment
Assignees
Labels
arch-wasm WebAssembly issues FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-JS
Milestone

Comments

@dmitshur
Copy link
Contributor

The recently-added js/wasm builder with Node v18.12.1 is reporting the following failure in compress/gzip:

(node:24834) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
node:internal/deps/undici/undici:10373
        performance.markResourceTiming(timingInfo, originalURL, initiatorType, globalThis2, cacheState);
                    ^

TypeError: performance.markResourceTiming is not a function
    at markResourceTiming (node:internal/deps/undici/undici:10373:21)
    at finalizeAndReportTiming (node:internal/deps/undici/undici:10369:7)
    at Object.handleFetchDone [as processResponseEndOfBody] (node:internal/deps/undici/undici:10316:45)
    at node:internal/deps/undici/undici:10630:44
    at node:internal/process/task_queues:140:7
    at AsyncResource.runInAsyncScope (node:async_hooks:203:9)
    at AsyncResource.runMicrotask (node:internal/process/task_queues:137:8)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Node.js v18.12.1
FAIL	compress/gzip	15.740s

If this needs significant changes to fix for Node 18 or requires dropping Node 14 support, it'll likely need to wait for the tree to reopen for Go 1.21 development. Putting in that milestone for now.

CC @golang/js, @golang/wasm, @johanbrandhorst.

@dmitshur dmitshur added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. arch-wasm WebAssembly issues OS-JS labels Dec 29, 2022
@dmitshur dmitshur added this to the Go1.21 milestone Dec 29, 2022
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/463234 mentions this issue: misc/wasm: use NodeJS performance library

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jan 28, 2023
johanbrandhorst added a commit to Pryz/go that referenced this issue Feb 12, 2023
The upgrade to NodeJS 18 introduces various library
updates that mean we can no longer override the global
performance package. Instead, rely on the performance
library provided by the NodeJS runtime.

Fixes golang#57516

Change-Id: Ic8ed902c696ad154f676e0b74b42efb84f02f8db
Reviewed-on: https://go-review.googlesource.com/c/go/+/463234
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Evan Phoenix <evan@phx.io>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
@golang golang locked and limited conversation to collaborators Jan 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly issues FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-JS
Projects
None yet
Development

No branches or pull requests

3 participants