Custom provider icon returns 0 response headers inside app but works outside

[hopewise]

Custom provider icon /icons/cp-admin-prod-icon.png fails to load in the app with "canceled" status and 0 response headers, while other provider icons load successfully using the same code.
Reproduction

Navigate to /providers page
View alerts table "Sources" column
Icon fails to load (0 bytes, canceled)

What Works

✅ Direct URL access: https://our-keep-domain.com/icons/cp-admin-prod-icon.png
✅ Other provider icons: sendgrid-icon.png, mysql-icon.png (identical code path)

What Fails

any custom icon we need to use, ex:

volumes:
      - ./icons/agg.png:/app/public/icons/cp-agg-prod-icon.png:ro
      - ./icons/staging.png:/app/public/icons/cp-admin-preprod-exceptions-icon.png:ro
      - ./icons/prod.png:/app/public/icons/cp-admin-prod-icon.png:ro

Key Detail
The request is canceled before any response headers are received, suggesting the server is blocking/rejecting it before sending a response. No console errors (CORS/CSP/etc).

Questions

Is there middleware or Next.js image optimization blocking this specific filename pattern?
Could custom icon be triggering server-side filtering?
Any file size/timeout limits that might affect this file specifically?

Request comparison and headers available if needed.

[dosubot[bot]]

There’s no middleware or Next.js image optimization blocking requests to /icons—those paths are explicitly excluded from middleware interception, and image optimization is disabled for provider icons in the app code cite. There’s also no filename-based filtering or file size limits for static assets in this path.

The most likely cause is a file access issue inside the container. The Next.js server runs as a non-root user (nextjs, UID 1001), so any custom icons mounted via Docker volumes (like /app/public/icons/cp-admin-prod-icon.png) must have permissions that allow read access by this user—typically 0644 or 0664 cite. If the permissions are too restrictive, the static server can’t serve the file, resulting in canceled requests with zero response headers.

Check that your mounted icon files are present inside the running container at /app/public/icons, and that their permissions allow read access for UID 1001. If you’re mounting individual files on top of an already-mounted /app tree (as in dev compose), make sure there’s no conflict or masking of assets.

If direct URL access works outside the app but fails inside, it’s almost always a file permission or mount issue in the container. Fixing the permissions should resolve the problem.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[hopewise]

ls -lah public/icons/
total 4M     
drwxrwxr-x    1 root     root         108 Dec 10 10:24 .
drwxrwxr-x    1 root     root          19 Jul 16 14:28 ..
-rw-rw-r--    1 root     root       21.2K Jul 16 14:28 airflow-icon.png
-rw-rw-r--    1 root     root       14.6K Jul 16 14:28 aks-icon.png
-rw-rw-r--    1 root     root       13.6K Jul 16 14:28 amazonsqs-icon.png
-rw-rw-r--    1 root     root       17.9K Jul 16 14:28 anthropic-icon.png
-rw-rw-r--    1 root     root       12.9K Jul 16 14:28 appdynamics-icon.png
-rw-rw-r--    1 root     root       31.9K Jul 16 14:28 argocd-icon.png
-rw-rw-r--    1 root     root       32.7K Jul 16 14:28 asana-icon.png
-rw-rw-r--    1 root     root        5.5K Jul 16 14:28 assert-icon.png
-rw-rw-r--    1 root     root       44.1K Jul 16 14:28 auth0-icon.png
-rw-rw-r--    1 root     root        4.1K Jul 16 14:28 axiom-icon.png
-rw-rw-r--    1 root     root      514.0K Jul 16 14:28 azuremonitoring-icon.png
-rw-rw-r--    1 root     root        2.5K Jul 16 14:28 bash-icon.png
-rw-rw-r--    1 root     root       14.6K Jul 16 14:28 bigquery-icon.png
-rw-rw-r--    1 root     root       13.4K Jul 16 14:28 centreon-icon.png
-rw-rw-r--    1 root     root        4.3K Jul 16 14:28 checkly-icon.png
-rw-rw-r--    1 root     root       15.9K Jul 16 14:28 checkmk-icon.png
-rw-rw-r--    1 root     root       13.0K Jul 16 14:28 cilium-icon.png
-rw-rw-r--    1 root     root        5.4K Jul 16 14:28 clickhouse-icon.png
-rw-rw-r--    1 root     root        5.0K Jul 16 14:28 cloudwatch-icon.png
-rw-rw-r--    1 root     root        3.5K Jul 16 14:28 console-icon.png
-rw-rw-r--    1 root     root        5.0K Jul 16 14:28 coralogix-icon.png
-rw-rw-r--    1 root     root       11.7K Dec 10 09:29 cp-admin-preprod-exceptions-icon.png
-rw-rw-r--    1 root     root       17.2K Dec 10 09:32 cp-admin-prod-icon.png
-rw-rw-r--    1 root     root       23.4K Dec 10 09:17 cp-agg-prod-icon.png

as you can see my custom icons have the same permissions as icons shipped.

-rw-rw-r--    1 root     root       11.7K Dec 10 09:29 cp-admin-preprod-exceptions-icon.png
-rw-rw-r--    1 root     root       17.2K Dec 10 09:32 cp-admin-prod-icon.png
-rw-rw-r--    1 root     root       23.4K Dec 10 09:17 cp-agg-prod-icon.png

[dosubot[bot]]

Your custom icons do have the right permissions and ownership, and there’s no middleware or Next.js logic blocking them by name or path. The most common cause for this kind of “canceled” request with zero response headers is a Docker volume mount or overlay issue: if you’re mounting individual icon files on top of an already-mounted directory (like the whole /app or /app/public/icons), Docker’s overlay order can mask or hide files, even if they appear in an ls listing inside the container. This can also happen if the file is missing or not readable by the running user (UID 1001, nextjs), but your permissions look fine.

To troubleshoot, exec into the running container and check the actual presence and readability of the icon files at /app/public/icons using commands like cat, file, or stat. Compare file hashes (sha256sum) inside the container and on the host to rule out overlay or corruption issues. If the files are present and readable, check the Next.js server logs for errors when the icon request fails. If everything looks correct, capture a browser network trace and compare request/response headers for working vs failing icons to spot subtle differences.

Based on all evidence, this almost always points to a runtime filesystem/mount issue rather than an app or code problem. Verifying the files inside the container at runtime is the most direct next step. For more details on how Docker mounts and overlays can cause this, see the relevant compose and Dockerfile configs and notes.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}