Report delivery - executing steps "asynchronously" and queueing tasks on which event loop?

[zcorpan]

https://w3c.github.io/reporting/#send-reports says

(3.3.) For each (origin, per-origin reports) pair in origin map, execute the following steps asynchronously:

(3.3.1.) Let result be the result of executing § 3.5.2 Attempt to deliver reports to endpoint on endpoint, origin, and per-origin reports.

Should that say "in parallel" instead of "asynchronously"?

-> https://w3c.github.io/reporting/#try-delivery

(3.) Queue a task to fetch request.

Which event loop is that queued for? Since sending reports is arbitrarily delayed, the window or worker from which they originated could be long gone, and their event loop too. Or even if it's from a document that has been navigated away but is still in history, it's not active, so tasks won't run until it's navigated back and activated.

Which is to say, I'm not sure it works to queue a task here. Presumably you want the reports to be sent when the UA tries to send them, regardless of the state or the originating context.

Am I missing something? Do implementations queue a task here?

[clelland]

See also #220 for the task queue question.

Some of the wording here comes from the previous version of this spec, where all reporting was out-of-band, and not tied to a particular window or worker. (That's still the case in the Chromium implementation, although that should change)

By the time we reach https://w3c.github.io/reporting/#send-reports, we have collected all of the reports which are going to be sent, and the UA should just send them. That should be done such that it doesn't block anything else, so I expected that queuing a task was still appropriate here.

[zcorpan]

If the steps are running in parallel, then they're not blocking other things.

@annevk is it OK to invoke "fetch" from in parallel steps?

[annevk]

Where does it go in parallel? If these steps are synchronous, no need to queue a task to fetch. And fetch can be used while in parallel in theory, but that's not fully worked out yet with respect to some global state grabbing it does early on.

[annevk]

Oh I see, "asynchronously". I think it's easier to use the "main thread" version of fetch here, along with its new callback arguments.