When testing resource fetching in an offline PWA context, behaviors differ depending on whether the revision query parameter is included:

• Plain URL request: await fetch("/resources/lib/test/chunk.js"); — Response successful (retrieved from server/cache depending on state).
• Revision URL request: await fetch("/resources/lib/test/chunk.js?__WB_REVISION__=639229280233797193"); — Fails or results in a mismatch if keys do not align with runtime expectations.

However, this is an expected behavior rather than a bug:

• The Service Worker caches each resource using its exact URL, including the cache-bust query string.
• This is intentional: since the cache-bust value changes on every deployment, it ensures that the application always loads the latest version of a resource rather than a stale cached version.
• The cache only recognizes the exact URL it stored. A plain URL without that query string represents a distinct lookup key to the cache, preventing an offline match unless fetched via the literal key stored in the browser developer tools (for example, Chrome DevTools). In normal Mendix usage, apps and standard widgets automatically load resources through framework-generated URLs, cache-bust parameters included.

Components with optimized loader chunking mechanisms (such as Webpack-based bundles in libraries like Apryse PDF WebViewer) perform dynamic code/asset imports via JavaScript fetch() or dynamic tag insertion.

• Because these libraries are unaware of Mendix revision parameters, they perform plain resource requests.
• Even when a cache.match check succeeds, the actual resource fetch fails due to strict Service Worker matching logic, rendering certain third-party components unusable in PWA offline scenarios without custom configuration or rewriting.

There is no single universal configuration switch for lax URL-prefix caching rules. Instead, modern releases address this through Rspack and the React client:

• Hashed bundling: Rspack takes relative dynamic imports into account during bundling and outputs files with unique hashed names.
• Caching safety: Because any content change produces a brand-new filename rather than reusing an old one, these files can be safely cached indefinitely. PWAs in this setup automatically pre-cache these entries without extra work.
• Limitations: The only exception remains when a third-party library loads additional files via internal runtime fetch() calls or script-tag insertion using self-computed URLs outside the bundler's module graph. Since those requests bypass the module graph, the framework cannot automatically make those files discoverable at the exact custom URL format expected by the library.