Task destination can stay null and then lead to undefined behavior

[jyasskin]

https://fetch.spec.whatwg.org/#concept-fetch starts with:

2. Let taskDestination be null.
3. ...
4. If request’s client is non-null, then:
   1. Set taskDestination to ...
5. If useParallelQueue is true, then set taskDestination to ...

So if client is null and useParallelQueue is false, taskDestination and so https://fetch.spec.whatwg.org/#fetch-params-task-destination stay null. But I don't see anything that blocks the later steps that call "Queue a fetch task ... with fetchParams’s task destination.", and Queue a fetch task assumes its task destination is non-null.

This also isn't mentioned in https://fetch.spec.whatwg.org/#fetch-elsewhere-request, which says "leave request’s client as null ... callbacks would be posted on a parallel queue" but doesn't tell callers to set useParallelQueue.

Should step 5 also set the taskDestination when client is null? Should there be an assertion that callers set either a client or useParallelQueue?

[domenic]

Should there be an assertion that callers set either a client or useParallelQueue?

I believe this is the intent. Indeed, maybe useParallelQueue should not be an explicit argument, and setting client to null should automatically cause the parallel queue to be used?

https://fetch.spec.whatwg.org/#fetch-elsewhere-request discusses this a bit:

Set your request’s client to the environment settings object you’re operating in. Web-exposed APIs are generally defined with Web IDL, for which every object that implements an interface has a relevant settings object you can use. For example, a request associated with an element would set the request’s client to the element’s node document’s relevant settings object. All features that are directly web-exposed by JavaScript, HTML, CSS, or other Document subresources should have a client.

If your fetching is not directly web-exposed, e.g., it is sent in the background without relying on a current Window or Worker, leave request’s client as null and set the request’s origin, policy container, service-workers mode, and referrer to appropriate values instead, e.g., by copying them from the environment settings object ahead of time. In these more advanced cases, make sure the details of how your fetch handles Content Security Policy and referrer policy are fleshed out. Also make sure you handle concurrency, as callbacks (see Invoking fetch and processing responses) would be posted on a parallel queue. [REFERRER] [CSP]

[...]

Note that the fetch operation starts in the same thread from which it was called, and then breaks off to run its internal operations in parallel. The aforementioned callbacks are posted to a given event loop which is, by default, the client’s global object. To process responses in parallel and handle interactions with the main thread by yourself, fetch with useParallelQueue set to true.