w3c / w3c/ServiceWorker

"Batch Cache Operations" contains a parable that confuses me

Open
#1,724 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Bikeshed
Stars
3.6k
Forks
324
Avg merge
14d 22h
Merged PRs (30d)
1

Description

https://w3c.github.io/ServiceWorker/#batch-cache-operations specifies the following step 4.2.3 under "Output":

If the result of running Query Cache with operation’s request, operation’s options, and addedItems is not empty, throw an "InvalidStateError" DOMException.

I don't understand how would this be correct for a "put" operation? To explain my confusion, I'd expect querying of the cache for which put method has been called, to maybe contain a cache hit for a matching request, meaning the "query cache" procedure may return a non-empty list (if equivalent request was there). Why should the implementation throw an InvalidStateError then? Or am I reading the entire parable in wrong context? The later step 4.2.6.6 instructs to run the "query cache" procedure again:

Set requestResponses to the result of running Query Cache with operation’s request.

Doesn't the above read more or less exactly like 4.2.3, while the latter already expects any result (an empty or non-empty list) while the former would have thrown had the cache querying returned a non-empty list?

I must be reading the spec. wrong, but I just can't seem to squint my eyes the right way to see if I can make sense of the above for my part.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read the Service Worker specification's “Batch Cache Operations” algorithm, especially step 4.2.3 under “Output” and step 4.2.6.6, alongside the linked “Query Cache” procedure. Determine whether the two steps are inconsistent or whether the surrounding conditions clarify their different roles; done means documenting the resolution or proposing precise spec wording.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.