- Extract /status route to server/routes/status.js
- Create server/services/WebhookStatus.js with checkWebhookConfigured and aggregateMetrics
- Slim dashboard.js to pure HTTP orchestration (559→283 lines, 49.4% reduction)
- Remove /user-summary and /webhook-metrics routes from dashboard.js
- Mount status router at /api/status in server/index.js and server/app.js
- Update tests to use new /api/status/status endpoint
- Fix test expectation for speed field (number vs string)
All 571 tests passing.
- Created server/services/DownloadBuilder.js with buildUserDownloads function
- Added private helpers: buildSeriesMapFromRecords, buildMoviesMapFromRecords, matchSabSlots, matchSabHistory, matchTorrents, getSlotStatusAndSpeed
- Updated server/routes/dashboard.js to use buildUserDownloads in /user-downloads and SSE /stream
- Removed ~500 lines of duplicated download-assembly logic
- All unit tests passing (DownloadBuilder: 14, DownloadAssembler: 73, TagMatcher: 26)
- Extract six pure tag-related functions from dashboard.js into new server/services/TagMatcher.js
- Functions: sanitizeTagLabel, tagMatchesUser, extractAllTags, extractUserTag, getEmbyUsers, buildTagBadges
- Update dashboard.js to import TagMatcher and replace all inline function calls
- Add comprehensive unit tests in tests/unit/services/TagMatcher.test.js (26 tests passing for 5 pure functions)
- Note: getEmbyUsers tests excluded due to CommonJS mocking complexity
The full pagination fix (ddad80a, e772001) caused history retrieval to
fetch up to 50 pages sequentially, taking 10-40 seconds instead of ~200ms.
Changes:
- Add maxPages parameter to getHistory() with default of 1 page
- Update poller to fetch 50 records (up from 10) in a single API call
- historyFetcher retains 100 records per page for UI display
This provides 5x more history for matching than before while keeping
the fast single-request performance.
Refs: develop-merge pagination performance issue
Sonarr Activity tab has 12 pages but we only fetched ~2 items.
Added pageSize=1000 to queue API and changed history default from 10 to 100.
This ensures all downloads are available for matching to SAB/qBittorrent.
Sonarr tracks the exact SAB download ID (nzo_id). Now tries to match
by downloadId first, then falls back to title matching. Also adds
debug to show if matches are via downloadId vs title, and logs
downloadIds in history to verify the link exists.
When a match is found, logs whether it came from queue or history.
When no match, shows history counts and sample titles to verify
history is being checked properly.
SAB items often persist after Sonarr has processed them.
Previously only checked the active queue, now also checks
history records so completed downloads still appear.
SAB filenames use dots (dora.the.explorer.s02e08) but Sonarr titles
use spaces (Dora the Explorer - S02E08). Now tries matching with
both formats to improve match rate.
Also logs actual Sonarr titles when no match found for debugging.
Shows exactly which SAB items match/don't match to Sonarr/Radarr:
- ✓ Sonarr match: SAB name → Sonarr name
- ✓ Radarr match: SAB name → Radarr name
- ✗ No match: SAB name (with Sonarr queue count)
This will help diagnose why Sonarr Activity Queue shows matches but Sofarr doesn't.
SABnzbd API returns labels as an array in newer versions,
but the code assumed it was a comma-separated string.
Now handles both cases to prevent 'slot.labels.split is not a function' error.
1. Fixed download client collision:
- SABnzbd client with id 'i3omb' was being overwritten by qBittorrent
- Now uses unique key ':' like the arr retrievers
2. Fixed webhook metrics showing 0:
- instanceName from webhooks is generic ('Sonarr', 'Radarr')
- Not the configured instance name ('i3omb')
- Now updates metrics for ALL instances of that type
When Sonarr and Radarr had the same instance ID (e.g., 'i3omb'),
the Radarr retriever would overwrite the Sonarr retriever in the Map.
This caused webhook refreshes to show '0 instance(s)' for Sonarr.
Now uses ':' as the unique key so both can coexist.
The status panel was showing webhooks as disabled (null) when no events
had been received yet. Now it checks Sonarr/Radarr API to see if the
Sofarr webhook notification is actually configured.
- Added checkWebhookConfigured() to verify webhook exists in Sonarr/Radarr
- Shows 'enabled: true' with 0 events when webhook is configured
- Only shows null when webhook is not configured at all
Add debug logging to trace:
- When downloads payload is built
- Data sizes from cache (SAB, qBit, Sonarr, Radarr)
- Number of downloads found and their titles
This will help diagnose why Dora downloads aren't appearing.
- Fixed webhooks section to load collapsed (content hidden, toggle arrow reset)
- Added webhook metrics card to status panel for admin users:
- Shows Sonarr/Radarr enabled/disabled status
- Shows events received and polls skipped counts
- Updated /api/dashboard/status endpoint to include webhook metrics
- Metrics are aggregated from all Sonarr/Radarr instances
The webhook notification payload was using string 'POST' for the method
field, but Sonarr/Radarr API expects numeric values:
- 1 = POST
- 2 = PUT
Also added onManualInteractionRequired: false to match the schema.
Fixes: Radarr/Sonarr rejecting webhook configuration with validation errors
The notification routes were using process.env.SONARR_URL directly,
which is undefined when using the newer SONARR_INSTANCES JSON format.
Changes:
- Added getFirstSonarrInstance() and getFirstRadarrInstance() helpers
- Updated /notifications, /notifications/test, and /notifications/sofarr-webhook
routes to use instance config from getSonarrInstances()/getRadarrInstances()
- Returns 503 error if no instances are configured
Fixes: 'Invalid URL' errors when calling Sonarr/Radarr notification APIs
Added detailed error logging to help diagnose 500 errors when calling
Sonarr/Radarr notification APIs. Logs include:
- Error message
- Response status (if available)
- Response data (if available)
This will help identify if the issue is:
- Missing SONARR_URL/RADARR_URL or API keys
- Network connectivity issues
- Sonarr/Radarr API version incompatibility
Webhook routes were only registered in app.js (the test factory) but
not in index.js (the production entry point). POST /api/webhook/*
was therefore falling through to the verifyCsrf middleware and being
rejected with 403 in production.
- Added POST /api/webhook/sonarr and POST /api/webhook/radarr endpoints
- Implemented webhook secret validation via SOFARR_WEBHOOK_SECRET environment variable
- Added logging for all incoming webhook events using existing logToFile utility
- Returns HTTP 200 immediately to prevent webhook retries
- Mounted webhook routes before CSRF middleware (called by external services)
- Non-breaking: no changes to polling, caching, SSE, or any existing behavior
- Lays groundwork for Phase 2 (cache + SSE integration) without implementing it yet
gronod
Gandalf