angular/angular · error · SwCriticalError

Cache is throwing while looking for a match: ${error}

Error message

Cache is throwing while looking for a match: ${error}

What it means

Inside the Angular service-worker script, serving a cached request requires cache.match() on CacheStorage; when that API itself throws (a known Safari 16.4/17 internal-error bug, or corrupted/evicted storage) the SW wraps it in SwCriticalError. The Driver catches critical errors and falls back to a safe network fetch, so requests still succeed but nothing is served from cache until the SW recovers.

Source

Thrown at packages/service-worker/worker/src/assets.ts:143

    // order to decide how to handle it.
    if (this.urls.indexOf(url) !== -1 || this.patterns.some((pattern) => pattern.test(url))) {
      // This URL matches a known resource. Either it's been cached already or it's missing, in
      // which case it needs to be loaded from the network.

      // Open the cache to check whether this resource is present.
      const cache = await this.cache;

      // Look for a cached response. If one exists, it can be used to resolve the fetch
      // operation.
      let cachedResponse: Response | undefined;
      try {
        // Safari 16.4/17 is known to sometimes throw an unexpected internal error on cache access
        // This try/catch is here as a workaround to prevent a failure of the handleFetch
        // as the Driver falls back to safeFetch on critical errors.
        // See #50378
        cachedResponse = await cache.match(req, this.config.cacheQueryOptions);
      } catch (error) {
        throw new SwCriticalError(`Cache is throwing while looking for a match: ${error}`);
      }

      if (cachedResponse !== undefined) {
        // A response has already been cached (which presumably matches the hash for this
        // resource). Check whether it's safe to serve this resource from cache.
        if (this.hashes.has(url)) {
          // This resource has a hash, and thus is versioned by the manifest. It's safe to return
          // the response.
          return cachedResponse;
        } else {
          // This resource has no hash, and yet exists in the cache. Check how old this request is
          // to make sure it's still usable.
          if (await this.needToRevalidate(req, cachedResponse)) {
            this.idle.schedule(`revalidate(${cache.name}): ${req.url}`, async () => {
              await this.fetchAndCacheOnce(req);
            });
          }

View on GitHub (pinned to 51cb07e980)

Solutions

1. Update Angular to a version that includes the Safari workaround (the try/catch around cache.match added for #50378).
2. Have affected users unregister the service worker and clear storage once, then reload to install a fresh SW.
3. If it persists across users, bump the app version in ngsw-config.json to force a clean reinstall.

When it happens

Trigger: A Safari 16.4/17.x browser performs a cache lookup during handleFetch and the Cache API throws internally (angular/angular#50378); or storage corruption/quota eviction makes cache.match() reject in any browser.

Common situations: PWA bug reports from Safari 16.4/17 users, especially on Angular versions predating the try/catch workaround; DevTools 'Clear site data' executed while the SW keeps serving another tab.

Related errors

• Failed to update the caches for request to '${req.url}' (fet
• Not a valid duration: ${match}
• Not a valid duration unit: ${res[2]}
• Asset-group '${group.name}' in 'ngsw-config.json' uses the '
• SERVICE_WORKER_DISABLED_OR_NOT_SUPPORTED_BY_THIS_BROWSER

AI-assisted analysis of angular/angular@51cb07e980 (2026-08-22). Data as JSON: /api/errors/91463f2d6e53c2d9. Report an issue: GitHub.