read_requests: v2 list routes 500 on all statuses except pending; tv search 500 #10

Closed
opened 2026-09-19 08:20:50 +01:00 by gronod · 2 comments
Owner

Summary

read_requests list returns UPSTREAM_REJECTED (HTTP 500) for movie and tv across every status except pending. search also 500s for tv (movie search works).

Environment

Reproduction

read_requests {"action":"list","media":"movie"}                          // 500
read_requests {"action":"list","media":"movie","status":"pending"}     // OK (empty)
read_requests {"action":"list","media":"movie","status":"processing"}  // 500
read_requests {"action":"list","media":"movie","status":"available"}   // 500
read_requests {"action":"list","media":"movie","status":"denied"}      // 500
read_requests {"action":"list","media":"movie","status":"unavailable"} // 500
read_requests {"action":"list","media":"tv"}                              // 500
read_requests {"action":"search","media":"tv","query":"button"}         // 500
read_requests {"action":"search","media":"movie","query":"yummy"}       // OK

Working actions: get (movie+tv_parent), children, recent, retry_queue.

Expected

Paged request lists and tv search results.

Actual

HTTP 500 passthrough on all listed routes.

Notes

The pending route working rules out auth/format problems — GET /api/v2/Requests/{media}/{status}/{take}/{skip}/requestDate/{dir} is well-formed. Most likely an Ombi-side serialization bug on request records present in the non-empty result sets (movie available has 1300+ records). The tv-search 500 may share the root cause (tv request records). Filed as suspected upstream — the MCP correctly surfaces UPSTREAM_REJECTED, but the failure makes the primary list path unusable and should be tracked/verified.

Correlation IDs

0e9657ee659de6a5c48f48d5 (movie all), ebfcaf6c0aad14fa4f24f99b (processing), 6378f79841696daf4bb4f250 (available), 0fee1e2cc41313574fdbd77e (denied), 7fa886a045ffa8433380a612 (unavailable), 46ec3fd5a20627a267dd328b (tv all), 37214cdae2c24f3040d7b42b (tv search)

## Summary `read_requests` `list` returns `UPSTREAM_REJECTED (HTTP 500)` for movie and tv across every status except `pending`. `search` also 500s for tv (movie search works). ## Environment - Binary: deployed darwin-amd64 build from `develop` @ `d047d76` - Ombi: 4.53.10 (https://ombi.i3omb.com), JWT auth ## Reproduction ```json read_requests {"action":"list","media":"movie"} // 500 read_requests {"action":"list","media":"movie","status":"pending"} // OK (empty) read_requests {"action":"list","media":"movie","status":"processing"} // 500 read_requests {"action":"list","media":"movie","status":"available"} // 500 read_requests {"action":"list","media":"movie","status":"denied"} // 500 read_requests {"action":"list","media":"movie","status":"unavailable"} // 500 read_requests {"action":"list","media":"tv"} // 500 read_requests {"action":"search","media":"tv","query":"button"} // 500 read_requests {"action":"search","media":"movie","query":"yummy"} // OK ``` Working actions: `get` (movie+tv_parent), `children`, `recent`, `retry_queue`. ## Expected Paged request lists and tv search results. ## Actual HTTP 500 passthrough on all listed routes. ## Notes The `pending` route working rules out auth/format problems — `GET /api/v2/Requests/{media}/{status}/{take}/{skip}/requestDate/{dir}` is well-formed. Most likely an Ombi-side serialization bug on request records present in the non-empty result sets (movie `available` has 1300+ records). The tv-search 500 may share the root cause (tv request records). Filed as suspected upstream — the MCP correctly surfaces `UPSTREAM_REJECTED`, but the failure makes the primary list path unusable and should be tracked/verified. ## Correlation IDs `0e9657ee659de6a5c48f48d5` (movie all), `ebfcaf6c0aad14fa4f24f99b` (processing), `6378f79841696daf4bb4f250` (available), `0fee1e2cc41313574fdbd77e` (denied), `7fa886a045ffa8433380a612` (unavailable), `46ec3fd5a20627a267dd328b` (tv all), `37214cdae2c24f3040d7b42b` (tv search)
gronod added this to the M5 — Request state and list routes milestone 2026-09-19 08:57:53 +01:00
Author
Owner

Retested on binary 6ebcb2f (M5 applied).

Search fallback does not work live. read_requests search {media:tv, query:"pemberley"} still returns UPSTREAM_REJECTED HTTP 500 with the upstream LINQ translation error (DbSet<TvRequests>.Where(t => t.Title.Contains(...))), corr 559fc935cbfb0a3232c5fec9. Per the code, the original error is only surfaced when the parent-scan fallback itself fails (failScan != nil) — so eachTVRequestParent (GET /api/v1/Request/tv/{count}/{pos}/1/0/0) is failing on this instance too (same failure class as the v2 lists, or a schema mismatch). No warning about the fallback attempt is emitted, which makes the failure opaque.

List 500s unchanged (accepted upstream bug, now with better detail). list for movie/tv on all/processing/available/denied/unavailable still 500s — now surfacing "Object reference not set to an instance of an object." via the improved error detail (e.g. corr 1bdff4ab61f9224bbb245b66). pending returns an empty page. Since the milestone documents these as upstream per-row NullReferenceException and intentionally preserves the v2 contract, this part is noted as upstream-wontfix — but the search fallback regression keeps this issue open.

What works: search movie, get tv_parent 908, children, recent, retry_queue, list pending.

Retested on binary `6ebcb2f` (M5 applied). **Search fallback does not work live.** `read_requests search {media:tv, query:"pemberley"}` still returns `UPSTREAM_REJECTED` HTTP 500 with the upstream LINQ translation error (`DbSet<TvRequests>.Where(t => t.Title.Contains(...))`), corr `559fc935cbfb0a3232c5fec9`. Per the code, the original error is only surfaced when the parent-scan fallback itself fails (`failScan != nil`) — so `eachTVRequestParent` (`GET /api/v1/Request/tv/{count}/{pos}/1/0/0`) is failing on this instance too (same failure class as the v2 lists, or a schema mismatch). No warning about the fallback attempt is emitted, which makes the failure opaque. **List 500s unchanged (accepted upstream bug, now with better detail).** `list` for movie/tv on `all`/`processing`/`available`/`denied`/`unavailable` still 500s — now surfacing `"Object reference not set to an instance of an object."` via the improved error detail (e.g. corr `1bdff4ab61f9224bbb245b66`). `pending` returns an empty page. Since the milestone documents these as upstream per-row `NullReferenceException` and intentionally preserves the v2 contract, this part is noted as upstream-wontfix — but the search fallback regression keeps this issue open. What works: `search movie`, `get tv_parent 908`, `children`, `recent`, `retry_queue`, `list pending`.
gronod reopened this issue 2026-09-19 15:13:48 +01:00
Author
Owner

Retested on post-M8 binary 958006c:

  • TV search fallback now works — search {media:tv, query:"pemberley"} returns the matching request via the bounded parent scan (warning: primary tv search route failed; fell back to parent scan). The RequestsViewModel wrapper decode fix (012f6c0) made the scan functional.
  • v2 list routes unchanged — list still 500s on all/processing/available/denied/unavailable for movie and tv (upstream per-row NullReferenceException, e.g. corr 1bdff4ab61f9224bbb245b66); pending returns an empty page. As documented, this part is an upstream bug the adapter surfaces natively.

Leaving open per milestone disposition — the fixable half is verified working; the upstream half remains reproducible.

Retested on post-M8 binary `958006c`: - **TV search fallback now works** — `search {media:tv, query:"pemberley"}` returns the matching request via the bounded parent scan (warning: `primary tv search route failed; fell back to parent scan`). The `RequestsViewModel` wrapper decode fix (`012f6c0`) made the scan functional. - **v2 list routes unchanged** — `list` still 500s on `all`/`processing`/`available`/`denied`/`unavailable` for movie and tv (upstream per-row `NullReferenceException`, e.g. corr `1bdff4ab61f9224bbb245b66`); `pending` returns an empty page. As documented, this part is an upstream bug the adapter surfaces natively. Leaving open per milestone disposition — the fixable half is verified working; the upstream half remains reproducible.
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gronod/ombi-mcp#10