Gandalf/sofarr
Public Access
0
0
Fork 0
Code Issues 1 Pull Requests Actions 1 Packages Projects Releases 59 Wiki Activity

BUG: Ombi TV show requests show "unknown" user + webhooks not reliably updating TV content #53

New Issue
Closed
opened 2026-05-27 08:55:21 +01:00 by Gandalf · 3 comments
Gandalf commented 2026-05-27 08:55:21 +01:00
Owner
Copy Link
Copy Source

Related to closed issue: #47 (Ombi webhook authentication fix)

Problem Summary

Even after the fix in commit 7b9c895 (which added ?secret= query parameter support for Ombi webhooks), two related issues remain:

  1. Ombi requests for TV shows are consistently flagged as "unknown" user in the dashboard and request lists.
  2. Webhooks for Ombi TV content appear not to be received (or do not trigger proper updates), while movie webhooks work correctly.

This breaks the core value proposition of linking downloads to the original Ombi requester, especially for TV shows.

Steps to Reproduce

  1. Configure Ombi instance(s) with OMBI_INSTANCES and enable webhooks via the one-click setup (SOFARR_BASE_URL + SOFARR_WEBHOOK_SECRET).
  2. Submit a TV show request in Ombi (any status: NewRequest, RequestAvailable, etc.).
  3. Wait for webhook or next poll cycle.
  4. Observe in sofarr:
    • The request appears in the Ombi requests list (or history) with user = "unknown".
    • No real-time update occurs for that TV request.
  5. Movie requests from the same Ombi instance work correctly (user is shown properly and updates are received).

Root Cause Analysis

Primary Cause: Incomplete user extraction for TV requests

File: server/utils/ombiHelpers.js → extractRequestedUser()

The function handles both object and string formats for requestedUser / RequestedUser and has good fallbacks for movies:

return requestedUser.alias || requestedUser.Alias || 
       requestedUser.userAlias || requestedUser.UserAlias || 
       requestedUser.userName || requestedUser.UserName || 
       requestedUser.normalizedUserName || requestedUser.NormalizedUserName || 
       request.requestedByAlias || ... || '';

However, Ombi TV show request objects (returned by Ombi’s /api/v1/Requests/tv endpoint and in webhook payloads) frequently use different field names or nesting for the requester:

  • user
  • requestedBy
  • ombiUser
  • requestedByUser
  • Nested structures under seasons[] for multi-episode requests

When none of the current fields match, the function returns an empty string (''), which is then displayed as "unknown" in the UI and filterRequestsByUser().

Movies work because their request objects consistently populate one of the supported fields.

Secondary Cause: Webhook processing appears ineffective for TV

File: server/routes/webhook.js

  • The Ombi webhook handler (POST /api/webhook/ombi) correctly authenticates (thanks to #47) and calls processWebhookEvent().
  • This triggers a full refresh of poll:ombi-requests (both movie and tv arrays) after a 2-second delay.
  • However, because TV requests in the refreshed data have incomplete/missing user information, the UI shows "unknown" and users perceive that "webhooks are not working" for TV content.
  • The 2-second hardcoded delay is a heuristic that does not always resolve the race condition with Ombi’s database commit.
  • No TV-specific logging or fallback exists when user extraction fails.

Expected Behavior

  • TV show requests from Ombi should correctly display the requester’s username (same as movies).
  • Ombi webhooks (for both NewRequest, RequestAvailable, etc.) should reliably update the TV request cache and trigger SSE updates in real time.
  • No "unknown" users for any Ombi-sourced content.

Proposed Solution

1. Improve extractRequestedUser() (highest priority)

Add more Ombi TV-specific fields and deeper fallback logic in server/utils/ombiHelpers.js:

// Add these to the priority list inside the object branch:
requestedUser.user || requestedUser.User ||
requestedUser.requestedBy || requestedUser.RequestedBy ||
requestedUser.ombiUser || requestedUser.OmbiUser ||
requestedUser.requestedByUser || requestedUser.RequestedByUser ||

// Also consider:
request.user?.alias || request.requestedBy?.alias || ...

Optionally add a small debug log when returning empty for a TV-type request.

2. Strengthen Ombi webhook reliability

  • Make the refresh delay configurable (env var OMBI_WEBHOOK_REFRESH_DELAY_MS, default 2000).
  • Add a short retry loop in processWebhookEvent for Ombi until the new request appears with valid user data.
  • Improve logging: always log the raw requestedUser object when extraction fails for TV events.

3. Minor improvements

  • Add a dedicated log line in the Ombi webhook handler for TV vs Movie differentiation.
  • In the frontend request cards, show “Unknown (Ombi)” with a tooltip or link to raw data when user is missing.
  • Include the date and time of requests in the request card
  • Include a Sonarr/Radarr icon in the request card for admin user (likely requires an additional lookup on tmdb id *are)

Additional Context

  • This bug was introduced or exposed after native HTTPS support and the Ombi webhook authentication fix (#47).
  • Affects all Ombi versions that return TV requests with non-standard user object shapes (very common).
  • No breaking changes required — purely additive improvements to extraction and reliability.
**Related to closed issue:** #47 (Ombi webhook authentication fix) ## Problem Summary Even after the fix in commit `7b9c895` (which added `?secret=` query parameter support for Ombi webhooks), two related issues remain: 1. **Ombi requests for TV shows are consistently flagged as "unknown" user** in the dashboard and request lists. 2. **Webhooks for Ombi TV content appear not to be received** (or do not trigger proper updates), while movie webhooks work correctly. This breaks the core value proposition of linking downloads to the original Ombi requester, especially for TV shows. --- ## Steps to Reproduce 1. Configure Ombi instance(s) with `OMBI_INSTANCES` and enable webhooks via the one-click setup (`SOFARR_BASE_URL` + `SOFARR_WEBHOOK_SECRET`). 2. Submit a **TV show request** in Ombi (any status: NewRequest, RequestAvailable, etc.). 3. Wait for webhook or next poll cycle. 4. Observe in sofarr: - The request appears in the Ombi requests list (or history) with **user = "unknown"**. - No real-time update occurs for that TV request. 5. Movie requests from the same Ombi instance work correctly (user is shown properly and updates are received). --- ## Root Cause Analysis ### Primary Cause: Incomplete user extraction for TV requests **File:** `server/utils/ombiHelpers.js` → `extractRequestedUser()` The function handles both object and string formats for `requestedUser` / `RequestedUser` and has good fallbacks for movies: ```js return requestedUser.alias || requestedUser.Alias || requestedUser.userAlias || requestedUser.UserAlias || requestedUser.userName || requestedUser.UserName || requestedUser.normalizedUserName || requestedUser.NormalizedUserName || request.requestedByAlias || ... || ''; ``` However, **Ombi TV show request objects** (returned by Ombi’s `/api/v1/Requests/tv` endpoint and in webhook payloads) frequently use **different field names or nesting** for the requester: - `user` - `requestedBy` - `ombiUser` - `requestedByUser` - Nested structures under `seasons[]` for multi-episode requests When none of the current fields match, the function returns an empty string (`''`), which is then displayed as **"unknown"** in the UI and `filterRequestsByUser()`. Movies work because their request objects consistently populate one of the supported fields. ### Secondary Cause: Webhook processing appears ineffective for TV **File:** `server/routes/webhook.js` - The Ombi webhook handler (`POST /api/webhook/ombi`) correctly authenticates (thanks to #47) and calls `processWebhookEvent()`. - This triggers a full refresh of `poll:ombi-requests` (both `movie` and `tv` arrays) after a 2-second delay. - However, because TV requests in the refreshed data have incomplete/missing user information, the UI shows "unknown" and users perceive that "webhooks are not working" for TV content. - The 2-second hardcoded delay is a heuristic that does not always resolve the race condition with Ombi’s database commit. - No TV-specific logging or fallback exists when user extraction fails. --- ## Expected Behavior - TV show requests from Ombi should correctly display the **requester’s username** (same as movies). - Ombi webhooks (for both NewRequest, RequestAvailable, etc.) should reliably update the TV request cache and trigger SSE updates in real time. - No "unknown" users for any Ombi-sourced content. --- ## Proposed Solution ### 1. Improve `extractRequestedUser()` (highest priority) Add more Ombi TV-specific fields and deeper fallback logic in `server/utils/ombiHelpers.js`: ```js // Add these to the priority list inside the object branch: requestedUser.user || requestedUser.User || requestedUser.requestedBy || requestedUser.RequestedBy || requestedUser.ombiUser || requestedUser.OmbiUser || requestedUser.requestedByUser || requestedUser.RequestedByUser || // Also consider: request.user?.alias || request.requestedBy?.alias || ... ``` Optionally add a small debug log when returning empty for a TV-type request. ### 2. Strengthen Ombi webhook reliability - Make the refresh delay configurable (env var `OMBI_WEBHOOK_REFRESH_DELAY_MS`, default 2000). - Add a short retry loop in `processWebhookEvent` for Ombi until the new request appears with valid user data. - Improve logging: always log the raw `requestedUser` object when extraction fails for TV events. ### 3. Minor improvements - Add a dedicated log line in the Ombi webhook handler for TV vs Movie differentiation. - In the frontend request cards, show “Unknown (Ombi)” with a tooltip or link to raw data when user is missing. - Include the date and time of requests in the request card - Include a Sonarr/Radarr icon in the request card for admin user (likely requires an additional lookup on tmdb id *are) --- ## Additional Context - This bug was introduced or exposed after native HTTPS support and the Ombi webhook authentication fix (#47). - Affects all Ombi versions that return TV requests with non-standard user object shapes (very common). - No breaking changes required — purely additive improvements to extraction and reliability.
Gandalf added the Kind/Bug
Priority
High
2
 labels 2026-05-27 08:55:21 +01:00
Gandalf commented 2026-05-27 17:43:12 +01:00
Author
Owner
Copy Link
Copy Source

Resolved in commit 95bd703b26.

Resolved in commit 95bd703b265503fa1d3b603d9ac6b5116e8f5e52.
Gandalf reopened this issue 2026-05-27 19:29:44 +01:00
Gandalf commented 2026-05-27 19:32:41 +01:00
Author
Owner
Copy Link
Copy Source

TV show requests are still displayed I correctly. The enhancement #55 to show request date and link also not working and status of TV show requests is "unknown"

TV show requests are still displayed I correctly. The enhancement #55 to show request date and link also not working and status of TV show requests is "unknown"
Gandalf commented 2026-05-27 21:41:45 +01:00
Author
Owner
Copy Link
Copy Source

Resolved in commit 33b122d. TV request status, user, and date are now correctly extracted from childRequests[] sub-objects. See CHANGELOG for details.

Resolved in commit 33b122d. TV request status, user, and date are now correctly extracted from childRequests[] sub-objects. See CHANGELOG for details.
Gandalf added the Area/Proxy label 2026-05-28 11:58:21 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Docker
Docker image and container packaging
 Area/Download Clients
Download client integrations
 Area/Frontend
Client-side UI and build tooling
 Area/History
History and completed downloads views
 Area/Logging
Log streaming, file handling, and debug infrastructure
 Area/Matching
Matching and correlation logic
 Area/Proxy
Upstream service proxy routes
 Area/SSE
Server-Sent Events and real-time streaming
 Area/Webhooks
Webhook processing and reliability
 Compat/Breaking
Breaking change that won't be backward compatible
 Compat/Non-Breaking
Non-breaking compatibility change
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label Area/Proxy Kind/Bug
Priority
High
2
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Gandalf
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Gandalf/sofarr#53
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?