In read_requestsrecent, movie items' target.id is the Ombi request id (usable with read_requests get), but tv_parent items' target.id is the provider id (TVDB), making it unusable for follow-up get calls.
Environment
Binary: deployed darwin-amd64 build from develop @ d047d76
{"target":{"kind":"movie","id":2207}, "title":"Yummy"} — 2207 is the request id (get works).
{"target":{"kind":"tv_parent","id":259032}, "title":"Seven Up!"} — 259032 is the tvdb id, not a request id. get {kind:tv_parent, id:259032} fails.
Expected
Consistent semantics: target.id is the Ombi request id for all kinds (request id of the tv parent), with provider ids exposed via identifiers.
Actual
For tv_parent, projectRequest populates target.id from the provider-id field (theTvDbId/providerId), while for movie it holds the request id. The recent handler then overwrites Target.ID with requestId only when present — for tv_parent the provider id survives in the target slot.
Impact
Consumers cannot resolve a tv_parent recent entry back to its request record (get, children, by_request) without another lookup.
Correlation ID
75fd4d712e4149ac8cdf43fd
## Summary
In `read_requests` `recent`, movie items' `target.id` is the Ombi request id (usable with `read_requests get`), but tv_parent items' `target.id` is the *provider* id (TVDB), making it unusable for follow-up `get` calls.
## Environment
- Binary: deployed darwin-amd64 build from `develop` @ `d047d76`
- Ombi: 4.53.10 (https://ombi.i3omb.com), JWT auth
## Reproduction
```json
read_requests {"action":"recent","page":{"limit":5}}
```
Returns e.g.:
- `{"target":{"kind":"movie","id":2207}, "title":"Yummy"}` — 2207 is the request id (`get` works).
- `{"target":{"kind":"tv_parent","id":259032}, "title":"Seven Up!"}` — 259032 is the *tvdb* id, not a request id. `get {kind:tv_parent, id:259032}` fails.
## Expected
Consistent semantics: `target.id` is the Ombi request id for all kinds (request id of the tv parent), with provider ids exposed via `identifiers`.
## Actual
For tv_parent, `projectRequest` populates `target.id` from the provider-id field (`theTvDbId`/providerId), while for movie it holds the request id. The recent handler then overwrites `Target.ID` with `requestId` only when present — for tv_parent the provider id survives in the target slot.
## Impact
Consumers cannot resolve a tv_parent recent entry back to its request record (`get`, `children`, `by_request`) without another lookup.
## Correlation ID
`75fd4d712e4149ac8cdf43fd`
gronod
added this to the M3 — Identity projection (discover → media → request) milestone 2026-09-19 08:58:01 +01:00
Fixed in #21 — read_requests recent now uses requestId as target.id for every kind; provider-shaped id values go in identifiers.
Fixed in https://git.i3omb.com/gronod/ombi-mcp/pulls/21 — `read_requests` recent now uses `requestId` as `target.id` for every kind; provider-shaped `id` values go in `identifiers`.
Retested on binary built from 019caca (M3 fix included) — still reproducible for TV rows. Movies and albums are fixed, but tv_parent targets still carry the provider id, not the Ombi request id.
Evidence (live, 2026-09-19):
read_requests recent →
tv_parent target.id=259032 Seven Up! (259032 = theTvDbId)
tv_parent target.id=56484 Death Comes to Pemberley (56484 = tmdb id; identifiers confirm tmdb:56484)
tv_parent target.id=273 Jimbo and the Jet Set (tmdb)
tv_parent target.id=118680 Bake Off Brasil: Celebridades (tmdb)
tv_parent target.id=77588 Great Celebrity Bake Off (tmdb)
movie target.id=2207 Yummy (real request id — works)
album target.id=132 Third Eye Blind (real request id — works)
Callable check:
read_requests get {kind: tv_parent, id: 908} → OK, returns "Death Comes to Pemberley" (908 is the real request id, also surfaced by read_discover browse tv requested → request_targets)
read_requests get {kind: tv_parent, id: 56484} → UPSTREAM_REJECTED HTTP 500 — the recent-emitted id is not callable (corr 085f6fece93915c9c912c168)
Root cause hypothesis: on Ombi's RecentlyRequestedModel, the requestId field on TV rows contains the provider id (or the projection's id fallback is reached because TV rows name the request id differently). Note the related read_requests children action also emits tv_child target.id=56484 — the provider id — so the same mis-mapping likely affects the children projection (GET /api/v1/Request/tv/{id}/child rows may carry the real child request id under a different field).
Retested on binary built from 019caca (M3 fix included) — **still reproducible for TV rows**. Movies and albums are fixed, but `tv_parent` targets still carry the provider id, not the Ombi request id.
Evidence (live, 2026-09-19):
```
read_requests recent →
tv_parent target.id=259032 Seven Up! (259032 = theTvDbId)
tv_parent target.id=56484 Death Comes to Pemberley (56484 = tmdb id; identifiers confirm tmdb:56484)
tv_parent target.id=273 Jimbo and the Jet Set (tmdb)
tv_parent target.id=118680 Bake Off Brasil: Celebridades (tmdb)
tv_parent target.id=77588 Great Celebrity Bake Off (tmdb)
movie target.id=2207 Yummy (real request id — works)
album target.id=132 Third Eye Blind (real request id — works)
```
Callable check:
- `read_requests get {kind: tv_parent, id: 908}` → OK, returns "Death Comes to Pemberley" (908 is the real request id, also surfaced by `read_discover browse tv requested` → `request_targets`)
- `read_requests get {kind: tv_parent, id: 56484}` → `UPSTREAM_REJECTED` HTTP 500 — the recent-emitted id is **not callable** (corr `085f6fece93915c9c912c168`)
Root cause hypothesis: on Ombi's `RecentlyRequestedModel`, the `requestId` field on TV rows contains the provider id (or the projection's `id` fallback is reached because TV rows name the request id differently). Note the related `read_requests children` action also emits `tv_child target.id=56484` — the provider id — so the same mis-mapping likely affects the children projection (`GET /api/v1/Request/tv/{id}/child` rows may carry the real child request id under a different field).
Milestone: M3 items otherwise verified — #2, #6, #9 confirmed fixed.
Fixed in PR #24 (merged to develop, fast-forward).
Root cause: Ombi builds recentlyRequested TV rows from child requests, so requestId is a child request id — and upstream persists the provider id as the child PK for new-request children. The value is provider-shaped (TVDB 259032, TMDB 56484) while the parent request id never appears in the payload. The earlier fix assumed requestId was always the request id, which holds for movie/album but not TV.
Fix: TV recent rows now resolve to the real parent request id through one bounded v1 parent scan (/api/v1/Request/tv/{count}/{pos}/1/0/0) — exact child-id match against embedded childRequests first, then a tvDbId/externalProviderId fallback. The child id is preserved as an ombi_tv_child identifier, provider ids land under tvdb/tmdb/imdb, and unresolvable rows emit target.id 0 with a warning rather than a provider-shaped target.
Verified live:recent now emits callable tv_parent targets (e.g. id 909 for Seven Up!, confirmed via read_requests get); TestLiveRecentTVParentTargetIsCallable covers this end-to-end.
Verdict on the children hypothesis:read_requests children was already faithful — upstream persists provider ids as the child PKs, so tv_child target.id=56484 is the real child request id (child-scoped delete/moderate accept it). As part of the fix, child projections now surface provider ids from the embedded parentRequest record.
Adjacent repairs on the same branch: the parent scan now decodes the real {"collection":[]} wrapper (it was dead on live, silently disabling the #7 overlay and #10 search fallback), and the details overlay gate treats requestId: 0 as absent (upstream sends 0, not a missing field).
Fixed in PR #24 (merged to develop, fast-forward).
**Root cause:** Ombi builds `recentlyRequested` TV rows from *child* requests, so `requestId` is a child request id — and upstream persists the provider id as the child PK for new-request children. The value is provider-shaped (TVDB `259032`, TMDB `56484`) while the parent request id never appears in the payload. The earlier fix assumed `requestId` was always the request id, which holds for movie/album but not TV.
**Fix:** TV recent rows now resolve to the real parent request id through one bounded v1 parent scan (`/api/v1/Request/tv/{count}/{pos}/1/0/0`) — exact child-id match against embedded `childRequests` first, then a `tvDbId`/`externalProviderId` fallback. The child id is preserved as an `ombi_tv_child` identifier, provider ids land under `tvdb`/`tmdb`/`imdb`, and unresolvable rows emit `target.id` 0 with a warning rather than a provider-shaped target.
**Verified live:** `recent` now emits callable `tv_parent` targets (e.g. `id 909` for Seven Up!, confirmed via `read_requests get`); `TestLiveRecentTVParentTargetIsCallable` covers this end-to-end.
**Verdict on the `children` hypothesis:** `read_requests children` was already faithful — upstream persists provider ids *as* the child PKs, so `tv_child target.id=56484` is the real child request id (child-scoped delete/moderate accept it). As part of the fix, child projections now surface provider ids from the embedded `parentRequest` record.
**Adjacent repairs on the same branch:** the parent scan now decodes the real `{"collection":[]}` wrapper (it was dead on live, silently disabling the #7 overlay and #10 search fallback), and the details overlay gate treats `requestId: 0` as absent (upstream sends 0, not a missing field).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
In
read_requestsrecent, movie items'target.idis the Ombi request id (usable withread_requests get), but tv_parent items'target.idis the provider id (TVDB), making it unusable for follow-upgetcalls.Environment
develop@d047d76Reproduction
Returns e.g.:
{"target":{"kind":"movie","id":2207}, "title":"Yummy"}— 2207 is the request id (getworks).{"target":{"kind":"tv_parent","id":259032}, "title":"Seven Up!"}— 259032 is the tvdb id, not a request id.get {kind:tv_parent, id:259032}fails.Expected
Consistent semantics:
target.idis the Ombi request id for all kinds (request id of the tv parent), with provider ids exposed viaidentifiers.Actual
For tv_parent,
projectRequestpopulatestarget.idfrom the provider-id field (theTvDbId/providerId), while for movie it holds the request id. The recent handler then overwritesTarget.IDwithrequestIdonly when present — for tv_parent the provider id survives in the target slot.Impact
Consumers cannot resolve a tv_parent recent entry back to its request record (
get,children,by_request) without another lookup.Correlation ID
75fd4d712e4149ac8cdf43fdFixed in #21 —
read_requestsrecent now usesrequestIdastarget.idfor every kind; provider-shapedidvalues go inidentifiers.Retested on binary built from
019caca(M3 fix included) — still reproducible for TV rows. Movies and albums are fixed, buttv_parenttargets still carry the provider id, not the Ombi request id.Evidence (live, 2026-09-19):
Callable check:
read_requests get {kind: tv_parent, id: 908}→ OK, returns "Death Comes to Pemberley" (908 is the real request id, also surfaced byread_discover browse tv requested→request_targets)read_requests get {kind: tv_parent, id: 56484}→UPSTREAM_REJECTEDHTTP 500 — the recent-emitted id is not callable (corr085f6fece93915c9c912c168)Root cause hypothesis: on Ombi's
RecentlyRequestedModel, therequestIdfield on TV rows contains the provider id (or the projection'sidfallback is reached because TV rows name the request id differently). Note the relatedread_requests childrenaction also emitstv_child target.id=56484— the provider id — so the same mis-mapping likely affects the children projection (GET /api/v1/Request/tv/{id}/childrows may carry the real child request id under a different field).Milestone: M3 items otherwise verified — #2, #6, #9 confirmed fixed.
Fixed in PR #24 (merged to develop, fast-forward).
Root cause: Ombi builds
recentlyRequestedTV rows from child requests, sorequestIdis a child request id — and upstream persists the provider id as the child PK for new-request children. The value is provider-shaped (TVDB259032, TMDB56484) while the parent request id never appears in the payload. The earlier fix assumedrequestIdwas always the request id, which holds for movie/album but not TV.Fix: TV recent rows now resolve to the real parent request id through one bounded v1 parent scan (
/api/v1/Request/tv/{count}/{pos}/1/0/0) — exact child-id match against embeddedchildRequestsfirst, then atvDbId/externalProviderIdfallback. The child id is preserved as anombi_tv_childidentifier, provider ids land undertvdb/tmdb/imdb, and unresolvable rows emittarget.id0 with a warning rather than a provider-shaped target.Verified live:
recentnow emits callabletv_parenttargets (e.g.id 909for Seven Up!, confirmed viaread_requests get);TestLiveRecentTVParentTargetIsCallablecovers this end-to-end.Verdict on the
childrenhypothesis:read_requests childrenwas already faithful — upstream persists provider ids as the child PKs, sotv_child target.id=56484is the real child request id (child-scoped delete/moderate accept it). As part of the fix, child projections now surface provider ids from the embeddedparentRequestrecord.Adjacent repairs on the same branch: the parent scan now decodes the real
{"collection":[]}wrapper (it was dead on live, silently disabling the #7 overlay and #10 search fallback), and the details overlay gate treatsrequestId: 0as absent (upstream sends 0, not a missing field).