/avatarproxy hangs forever instead of responding when the user ID is invalid

[manuvega-ai]

Description

GET /avatarproxy/:jellyfinUserId never sends a response when the path parameter
fails the 32-hex validation check. The request hangs until the client or an
upstream proxy times out.

In server/routes/avatarproxy.ts, the handler throws when the parameter does not
match /^[a-f0-9]{32}$/, and the catch block logs the error but never calls
res:

} catch (e) {
  logger.error('Failed to proxy avatar image', {
    errorMessage: e.message,
  });
}

Since nothing is sent and next(e) is not called, Express keeps the request open
indefinitely. The route is mounted outside /api/v1 (server/index.ts), so it is
not covered by the OpenAPI validator and requires no authentication — an
unauthenticated request can hold a server connection open with no rate limit.
Behind a reverse proxy this surfaces as a gateway timeout (Cloudflare returns 524
after 100s).

Still present on develop as of this report.

Suggested fix

Send a response on the error path, e.g.:

} catch (e) {
  logger.error('Failed to proxy avatar image', {
    errorMessage: e.message,
  });
  if (!res.headersSent) {
    res.status(400).send('Invalid avatar request');
  }
}

Returning 404 instead of 400 would be equally reasonable. Validating the parameter
before entering the try block would also work.

Version

3.4.1

Steps to Reproduce

1. Run any Seerr instance.
2. curl -m 15 -o /dev/null -w '%{http_code} %{time_total}\n' http://<host>:5055/avatarproxy/1
3. Observe no response — curl reports 000 at the timeout instead of a status code.
4. For contrast, curl http://<host>:5055/avatarproxy/00000000000000000000000000000000
   returns 200 with an image in well under a second.

Any value that is not exactly 32 lowercase hex characters reproduces it
(/avatarproxy/abc, /avatarproxy/1, etc.).

Note: this reproduces regardless of media server type. It was found on a
Plex-backed instance, where /avatarproxy is never used by the frontend at all —
those URLs are only generated for Jellyfin/Emby users — so the endpoint is
reachable and hangs even on installs that have no use for it.

Screenshots

No response

Logs

2026-09-08T01:32:32.635Z [error][API]: Failed to proxy avatar image {"errorMessage":"Provided URL is not an Emby avatar."}

$ curl -m 15 -o /dev/null -w 'HTTP %{http_code} after %{time_total}s\n' http://127.0.0.1:5055/avatarproxy/1
HTTP 000 after 15.001360s

$ curl -m 15 -o /dev/null -w 'HTTP %{http_code} after %{time_total}s\n' http://127.0.0.1:5055/avatarproxy/00000000000000000000000000000000
HTTP 200 after 0.009405s

Platform

desktop

Database

SQLite (default)

Device

Desktop PC

Operating System

Windows 11

Browser

Chrome 152

Additional Context

No response

Search Existing Issues

• Yes, I have searched existing issues.

Code of Conduct

• I agree to follow Seerr's Code of Conduct

[aron-intframe]

Confirmed, and the hang is wider than a malformed id: the same catch swallows every failure in that handler, so a perfectly valid 32-hex id also hangs whenever the image fetch fails.

The reachable second path is on develop today:

• server/routes/avatarproxy.ts:155 and :158 both call avatarImageCache.getImage(fallbackUrl) with no fallbackPath argument (both the user?.avatarVersion branch and the else branch end there).
• server/lib/imageproxy.ts:167-175: when set() returns nothing and no fallbackPath was passed, getImage does throw new Error('Failed to load image').
• That throw lands in the same catch at avatarproxy.ts:175-179, which logs and returns. No res, no next(e).

So any install that cannot reach gravatar.com (blocked egress, offline LAN, DNS hole) hangs on legitimate avatar requests, for real Jellyfin/Emby users, not just on /avatarproxy/1. That also means "validate the param before the try" does not fix it on its own.

I reproduced both paths by lifting the handler body out of develop into a bare Express app on the same versions the repo pins (express 5.2.1), with getImage stubbed to the imageproxy.ts:167-175 contract. Test 3 is the case the report does not cover.

$ node repro.js
express 5.2.1 | node v20.20.2 

--- 1. upstream reachable, malformed id (the reported case)
[server log] Failed to proxy avatar image {"errorMessage":"Provided URL is not a Jellyfin avatar."}
HTTP 000 (no response) after 5.008s   /avatarproxy/1

--- 2. upstream reachable, valid 32-hex id
HTTP 200 after 0.003s   /avatarproxy/00000000000000000000000000000000

--- 3. upstream UNREACHABLE, valid 32-hex id (gravatar/jellyfin down)
[server log] Failed to proxy avatar image {"errorMessage":"Failed to load image"}
HTTP 000 (no response) after 5.000s   /avatarproxy/00000000000000000000000000000000

--- 4. same two requests against a catch that answers
[server log] Failed to proxy avatar image {"errorMessage":"Provided URL is not a Jellyfin avatar."}
HTTP 404 after 0.003s   /patched/1
[server log] Failed to proxy avatar image {"errorMessage":"Failed to load image"}
HTTP 404 after 0.001s   /patched/00000000000000000000000000000000

--- 5. sockets still held open by the server after 3 hung requests
[server log] Failed to proxy avatar image {"errorMessage":"Provided URL is not a Jellyfin avatar."}
[server log] Failed to proxy avatar image {"errorMessage":"Provided URL is not a Jellyfin avatar."}
[server log] Failed to proxy avatar image {"errorMessage":"Provided URL is not a Jellyfin avatar."}
open connections = 5

Notes on the output: case 1 is the reported malformed id. Case 3 is a valid 32-hex id with the upstream unreachable, same silence. Case 5 shows the server still holding 5 sockets, the 3 requests just fired plus the two from cases 1 and 3 that were never answered and are still open minutes later; the client timing out does not free them, curl -m only stops the client waiting.

The fix already exists next door. server/routes/imageproxy.ts:70-74 ends its catch with res.status(500).send(). Matching that shape in avatarproxy.ts closes both classes at once:

  } catch (e) {
    logger.error('Failed to proxy avatar image', {
      errorMessage: e.message,
    });
    if (!res.headersSent) {
      res.status(404).send('Invalid avatar request');
    }
  }

404 reads better than 400 here since a fetch failure is not a client error, but either is fine; the point is that the handler must always terminate the response. next(e) also works and would let the shared error handler answer, but it is the larger change since the route is mounted outside /api/v1 at server/index.ts:260.

We keep a catalog of this failure family, where the only evidence a failure produced was a log line and the caller saw nothing at all, including the case where a request timeout is itself the only signal (ours): https://github.com/aron-intframe/agent-guards

[gauthier-th]

For the fix, the next() function should be used instead, like in the rest of the project.