Push Notifications Broken: Service Worker Fails on 404 Precache

[hrmtc]

Describe the bug

Push notifications do not work in production because the service worker never finishes installing. The SW generated by @ducanh2912/next-pwa includes /_next/dynamic-css-manifest.json in its precache list, but that URL returns 404 in the Docker deployment. Workbox aborts the install step with:

bad-precaching-response :: [{"url":"https://<host>/_next/dynamic-css-manifest.json","status":404}]

Since the service worker remains stuck in “installing”, web push doesn’t initialize and notifications are broken.

To Reproduce

1. Deploy SplitPro using the production docker/prod/compose.yml (image ossapps/splitpro:latest; Next.js standalone output).
2. Open the app in Chrome and go to DevTools → Application → Service Workers.
3. Register the SW (navigator.serviceWorker.register('/sw.js')) or reload the page.
4. See console error: bad-precaching-response for /_next/dynamic-css-manifest.json (404).
   The SW never activates; push subscription cannot be established.

Expected behavior

• Service worker installs and activates without errors.
• Push notifications can be subscribed and delivered.

Screenshots

• DevTools console shows:

• Service worker remains stuck in “installing” (DevTools → Application → Service Workers).

App version

• Docker image: ossapps/splitpro:latest
• Next.js: 15.4.7 (standalone output)
• @ducanh2912/next-pwa: 10.2.9
• Build ID available if needed (/_next/static/<BUILD_ID>)

Desktop
OS: macOS
Browser: Chrome
Version: 141

Device: iPhone
OS: iOS 13
Browser: Safari (Mobile)
Version: iOS26

Additional context

Root cause: In Next.js standalone builds, /_next/dynamic-css-manifest.json exists on disk but is not routable; requests return 404. Because the SW precache includes this path, Workbox treats the 404 as a failure and aborts installation.

Workaround used: Manually edit /app/public/sw.js in the running container to remove the precache entry { url: "/_next/dynamic-css-manifest.json", ... }.
After removing it, the SW installs and push notifications work. This manual change is not persistent across image rebuilds.

Proposed fix: Exclude that path from precaching in next.config.js (next-pwa config), e.g.:

const withPWA = (await import('@ducanh2912/next-pwa')).default({
  dest: 'public',
  disable: process.env.NODE_ENV === 'development',
  buildExcludes: [/_next\/dynamic-css-manifest\.json$/],
});

With this exclusion, the generated service worker installs cleanly and push notifications work out of the box.

[hrmtc]

PR opened with the fix: #446 — it excludes /_next/dynamic-css-manifest.json from the next-pwa precache so the service worker can install and push notifications start working again.
All CI checks are green; happy to adjust if you need anything else.

Please keep the issue open until the PR is merged.

[hrmtc]

Thanks for shipping the service worker fix!

@krokosik

Quick heads-up: the Docker image ossapps/splitpro:latest still seems to be built from the pre-fix code. I pulled it today (docker pull ossapps/splitpro:latest) and the container still serves /app/public/sw.js with /_next/dynamic-css-manifest.json in the precache list. Hitting /_next/dynamic-css-manifest.json from inside the container returns 404, so the service worker gets stuck installing and push notifications remain broken.

Looks like the image on Docker Hub just hasn’t been rebuilt since the fix merged. Could you publish a refreshed image (or set up an automatic build on merge)? That should bring push notifications back for the Docker deployment.

Thanks!

[krokosik]

The image that was published is from the v1.5.5 tag, which does have the fix included. Could you double check that you actually pulled the updated image? With latest you need to call docker compose pull to get the new image.

[hrmtc]

The image that was published is from the v1.5.5 tag, which does have the fix included. Could you double check that you actually pulled the updated image? With latest you need to call docker compose pull to get the new image.

I pulled ossapps/splitpro:latest again today and double‑checked what it ships.

docker pull ossapps/splitpro:latest resolves to digest sha256:cb3d37bade8784cf38331046c673da5c3e2fb86ce65e776eb953c49a2f03cb9e (built 2025‑10‑22).
Running a fresh container from that image, /app/public/sw.js still includes /_next/dynamic-css-manifest.json in the precache array, and hitting /_next/dynamic-css-manifest.json inside the container returns 404.
The bundled app is the older build (Next 15.3.3, Prisma 6.8.2, build id o3HZa6bEyuASyvhkmR420).
So it looks like latest is still pointing to the pre‑fix image. Happy to retest as soon as a new digest is published!

[krokosik]

I just pulled the 1.5.5 image and run docker exec -it splitpro cat next.config.js and confirmed the buildExcludes: [/_next\/dynamic-css-manifest\.json$/], line is there. So either you did not pull the latest image or the fix doesn't work.

However, I can confirm that the service worker still does not install. It has gone unnoticed, because most users (including me) already had a worker set up from previous SP versions. Once I unregistered the worker it does not get installed again and I looked into the next-pwa/serwist repo for a fix. Indeed there were issues regarding Next 15 not working, which we upgraded to in v1.5. So I guess we should migrate to serwist and see if it fixed the issue.

[krokosik]

Try the new 1.5.6 release and see if the situation improved.

[hrmtc]

Hi @krokosik, we just tested push notifications on 1.5.6 and they’re working correctly now. One caveat: the current schema only keeps a single subscription per user, so registering a second device will overwrite the first and the earlier device will stop receiving pushes. Would it be feasible to bring back multi-device support so each user can keep multiple subscriptions active? Thanks a lot for all your effort getting this release out—much appreciated!

[krokosik]

@hrmtc the subscriptions were always like this, see the prisma schema. I agree though that it should be improved, but I will be travelling for a week and a change like this (new feature) is probably more appropriate to go to 1.6. Can you create a new issue for this?