feat(ext/fetch): support priority in RequestInit#34716
Merged
Merged
Conversation
`Request`/`RequestInit` were missing the `priority` member from the
Fetch standard ("auto" | "high" | "low"), so `new Request(url, { priority })`
silently ignored the option, `request.priority` was `undefined`, and an
invalid value did not throw.
This adds the `RequestPriority` enum, the `priority` getter (defaulting
to "auto"), and wires the option through the constructor and
`cloneInnerRequest`. As with the other request properties, the value is
not acted upon by the underlying networking stack (priority hints have no
effect in a server runtime); this is for spec/browser parity.
Closes #16502
Per the Fetch spec, priority is a RequestInit member (write-only init option), not a readonly attribute on the Request interface. Exposing it as a getter failed WPT fetch/api/request/request-structure.any.js, which asserts Request does not expose the priority attribute. Keep the RequestInit.priority side: it is still accepted, validated as a RequestPriority enum (invalid values throw), and stored internally. Only the public getter and its .d.ts declaration are removed.
bartlomieju
changed the title
priority on Request and RequestInitpriority in RequestInit
bartlomieju
enabled auto-merge (squash)
June 6, 2026 12:32
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds the
prioritymember from the Fetch standard toRequestInit(
"auto"|"high"|"low").Before this,
new Request(url, { priority })silently ignored the optionand passing an invalid value did not throw, diverging from browsers and
Node. This follows up #34607, which added the other missing
Requestproperties but left out
priority.In the Fetch standard
priorityis a write-onlyRequestInitmember, nota readonly attribute on the
Requestinterface, so it is accepted andvalidated but intentionally not exposed back as
request.priority. The WPTfetch/api/request/request-structuretest asserts exactly this ("Requestdoes not expose priority attribute"), and browsers behave the same way.
Changes:
RequestPriorityenum converter soinit.priorityis validatedand invalid values throw a
TypeErrorinit.prioritythrough the constructor andcloneInnerRequestRequestPriorityandRequestInit.prioritytolib.deno_fetch.d.tstests/unit/request_test.tsand flip therequest-init-priorityWPT expectations to passing
As with the other request properties, the value isn't acted upon by the
underlying networking stack (priority hints have no meaningful effect in a
server runtime); this is for spec/browser parity.
Closes #16502