fix(seerr): stop rewriting the root link inside the JS bundle (#2975) (#2986)

* fix(seerr): stop rewriting the root link inside the JS bundle (#2975)

3.4.1.1 appended a trailing slash to both the server-rendered "Discover"
link and its counterpart inside Seerr's JavaScript bundle. The slash is
correct in the HTML - Home Assistant routes ingress on
"/api/hassio_ingress/{token}/{path:.*}" and rejects a slash-less entry -
but it cannot survive in the bundle: next/link resolves a pushed href
through normalizePathTrailingSlash(), which drops a trailing slash while
`trailingSlash` is false, and Next.js then hard navigates to the
slash-less URL, recreating the same 404. On the root page it instead
throws "Invariant: attempted to hard navigate to the same URL" and the
click does nothing.

Dropping the bundle rewrite leaves the link as "/", which the client
router matches against its own "/" route and transitions to in-app -
the same path every other sidebar entry already takes, none of which are
rewritten here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(seerr): drop text/html from sub_filter_types

nginx pre-seeds text/html into sub_filter_types, so listing it emits
`[warn] duplicate MIME type "text/html"` on every config load. Verified
against nginx 1.22.1 locally: with the type dropped, `nginx -t` is
warning free and an HTML response is still filtered.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

birdnet-go-dev/rootfs/etc/nginx/servers/ingress.conf

@@ -49,7 +49,6 @@ server {
       sub_filter `/asset `%%ingress_entry%%/asset;
       sub_filter "'/asset" "'%%ingress_entry%%/asset";
       sub_filter \"/asset \"%%ingress_entry%%/asset;
-      sub_filter \"/auth \"%%ingress_entry%%/auth;
       sub_filter window.location.origin} window.location.origin}%%ingress_entry%%;
     }
 }

birdnet-go/rootfs/etc/nginx/servers/ingress.conf

@@ -49,7 +49,6 @@ server {
       sub_filter `/asset `%%ingress_entry%%/asset;
       sub_filter "'/asset" "'%%ingress_entry%%/asset";
       sub_filter \"/asset \"%%ingress_entry%%/asset;
-      sub_filter \"/auth \"%%ingress_entry%%/auth;
       sub_filter window.location.origin} window.location.origin}%%ingress_entry%%;
     }
 }

seerr/CHANGELOG.md

@@ -1,4 +1,8 @@
  
+## 3.4.1.2 (2026-08-18)
+
+- Fixed **Discover** in the sidebar still failing through ingress after 3.4.1.1 (#2975). The trailing slash added in 3.4.1.1 was also applied to the copy of the link inside Seerr's JavaScript bundle, and Next.js' client-side router strips a trailing slash before navigating: it then sent the click to a URL Home Assistant does not route, so it either landed on the same `404: Not Found` or threw `Invariant: attempted to hard navigate to the same URL` and did nothing at all. The bundle is no longer rewritten, so **Discover** routes inside the app exactly like **Requests**, **Issues** and **Settings** already did. The server-rendered link keeps its trailing slash. Only ingress was affected; the directly published port 5055 always worked.
+
 ## 3.4.1.1 (2026-08-16)
 
 - Fixed `404: Not Found` when clicking **Discover** in the sidebar through ingress (#2975). Seerr's Discover link points at `/`, which nginx rewrote to the ingress entry without a trailing slash; Home Assistant only routes ingress on `/api/hassio_ingress/<token>/…`, so the request was rejected by Home Assistant before reaching the add-on. Only ingress was affected; the directly published port 5055 always worked.

seerr/config.yaml

@@ -96,4 +96,4 @@ schema:
 slug: seerr
 udev: true
 url: https://github.com/alexbelgium/hassio-addons/tree/master/seerr
-version: "3.4.1.1"
+version: "3.4.1.2"

seerr/rootfs/etc/nginx/servers/ingress.conf

@@ -43,17 +43,40 @@ server {
 
         sub_filter_once off;
 
-        # Do not rewrite every response type blindly.
-        sub_filter_types text/html application/javascript text/javascript application/json;
+        # Do not rewrite every response type blindly. text/html is implicit and
+        # must not be listed - nginx pre-seeds it and warns "duplicate MIME type"
+        # on every config load if it appears here as well.
+        sub_filter_types application/javascript text/javascript application/json;
 
-        # The trailing slash is required: Home Assistant routes ingress on
-        # "/api/hassio_ingress/{token}/{path:.*}", so the bare entry without it
-        # matches no route and Home Assistant answers its own plain-text
-        # "404: Not Found" before the request ever reaches this add-on. Seerr's
-        # Discover link is href="/", so without the slash every click on it 404s.
+        # Seerr's "Discover" sidebar entry, the header logo and the 404 and
+        # error pages are all <Link href="/">. The server-rendered anchor has to
+        # carry the ingress prefix *with* a trailing slash: Home Assistant routes
+        # ingress on "/api/hassio_ingress/{token}/{path:.*}", so a slash-less
+        # entry matches no route and Home Assistant answers its own plain-text
+        # "404: Not Found" before the request ever reaches this add-on (#2975).
         sub_filter 'href="/"' 'href="$app/"';
         sub_filter 'href="/login"' 'href="$app/login"';
-        sub_filter 'href:"/"' 'href:"$app/"';
+
+        # A matching rule for 'href:"/"' - the form those same links take once
+        # compiled into the JS bundle - used to sit here. It is gone on purpose
+        # and must not come back: it fed the ingress prefix into Next.js' own
+        # route table, and next/link resolves a pushed href through
+        # normalizePathTrailingSlash(), which drops a trailing slash while
+        # `trailingSlash` is false (Seerr sets no override). Next therefore hard
+        # navigated to the slash-less URL and recreated the same 404; on the root
+        # page it instead threw "Invariant: attempted to hard navigate to the
+        # same URL" and the click did nothing. That is the state PR #2976 left
+        # #2975 in. Left alone the href stays "/", which removeTrailingSlash()
+        # preserves, so the router matches its own "/" route and transitions
+        # in-app - the path every other sidebar entry ("/requests", "/issues",
+        # "/users", "/settings") already takes. Prefixing belongs in the rendered
+        # anchor, never in the router's route table.
+        #
+        # Note that none of these rules are response-type scoped - sub_filter_types
+        # includes JavaScript - so the anchor rule above avoids the bundle only
+        # because the compiled output spells the prop 'href:"/"' and not
+        # 'href="/"'. These are textual substitutions over someone else's minified
+        # output: recheck them whenever Seerr or Next.js is upgraded.
         sub_filter '\/_next' '%%ingress_entry_escaped%%\/_next';
         sub_filter '/_next' '$app/_next';
         sub_filter '/api/v1' '$app/api/v1';