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>
This commit is contained in:
Alexandre
2026-08-18 13:29:01 +02:00
committed by GitHub
parent 2b6e07040f
commit 84dfd1b996
3 changed files with 36 additions and 9 deletions

View File

@@ -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.

View File

@@ -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"

View File

@@ -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';