[w3c/ServiceWorker] Editorial: use a dedicated parallel queue for the Clients API (PR #1842)

Closes #1840. Follow-up to #1755.

Give each {{Clients}} object a dedicated parallel queue and route the operations on {{Clients}} through it, so operations on the same {{Clients}} object do not race with each other (e.g. `matchAll` iterating over service worker clients while `claim` is mutating their [=active service worker=]).

## Changes

- Add a `<dfn export for="Clients">Clients parallel queue</dfn>` (a [=parallel queue=]) attached to each {{Clients}} object, following the same pattern as the `name to cache map parallel queue` introduced in #1838.
- Route the following method algorithms through it, replacing their existing top-level `Run … in parallel` block:
    - {{Clients/get(id)}}
    - {{Clients/matchAll(options)}}
    - {{Clients/openWindow(url)}}
    - {{Clients/claim()}}
- Wrap the two remaining bare `Resolve |promise| with undefined.` steps (in `get()` and `claim()`) in `Queue a task` on `|promise|`'s [=responsible event loop=] using the [=DOM manipulation task source=], matching the pattern already used in `matchAll()` and consistent with the queue-a-task refactor from #1755.

Total change: **+10 / −6** in `index.bs`, one commit.

## Rationale

Yoshi flagged this concern during #1755 review:

> I just wondered what happens if one of the service worker clients has been removed or gets execution ready flag during the sub step execution, and suggest to run Clients API algorithm within the dedicated parallel queue to prevent unexpected modifications to clients.

#1836 landed the queue-a-task-for-resolve fixes for these methods. This PR delivers the sibling parallel-queue work that was explicitly deferred in the [split plan](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-4963401716).

## Out of scope

- {{Client/postMessage(message, options)}} — lives on {{Client}}, not {{Clients}}, and does a single-client lookup rather than iterating the full client list. Can be a further follow-up if needed.
- {{WindowClient/focus()}} and {{WindowClient/navigate(url)}} — already skip the `in parallel` block entirely and use `Queue a task` on the client's own event loop, so no parallel-queue treatment is meaningful for them.

## Related

- #1755 — parent (queue-a-task refactor)
- #1836 — Clients API queue-a-task-for-resolve (merged)
- #1740 — original missing-tasks-in-parallel issue
- #1172 — umbrella "Carefully audit all uses of 'in parallel' in the spec"
- #1838 — sibling PR (CacheStorage-level parallel queue), same dfn pattern
- #1841 — sibling PR (per-cache parallel queue), same dfn pattern


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/monica-ch/ServiceWorker/pull/1842.html" title="Last updated on Aug 4, 2026, 9:14 PM UTC (7f622b8)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/ServiceWorker/1842/e91ddff...monica-ch:7f622b8.html" title="Last updated on Aug 4, 2026, 9:14 PM UTC (7f622b8)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/ServiceWorker/pull/1842

-- Commit Summary --

  * Editorial: use a dedicated parallel queue for the Clients API

-- File Changes --

    M index.bs (16)

-- Patch Links --

https://github.com/w3c/ServiceWorker/pull/1842.patch
https://github.com/w3c/ServiceWorker/pull/1842.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1842
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1842@github.com>