Improve Task Logging

Is there an existing issue for this?

• I have searched the existing open and closed issues

Is your feature request related to a problem? Please describe

When I trigger a manual search for an episode, theres really no single place to see what actually happened. The search runs under System > Tasks and then disappears pretty quick. If something gets grabbed it shows up in History. If it starts downloading it shows up in Activity > Queue. If nothing gets grabbed, theres basically no record that the search even finished or why it didn’t find anything.

So I end up bouncing between three different views just to answer a simple question like "I searched for S05E14 of Ted Lasso, did it work?"

It gets even worse when searching for multiple episodes or a whole season. Theres no clear way to tell which ones found something, which are still running, and which ones failed or just came up empty.

Describe the solution you'd like

A new Searches tab under Activity (/activity/searches) that shows recent user triggered searches and updates rows as Sonarr picks up grabs, downloads, and imports.

Suggested approach inside the new tab:

• Flat rows, one per episode, same pattern as Queue
• Read only view, no queue manipulation
• Completed rows get cleaned up after 24 hours and active ones stick around until they hit a final state
• Updates pushed out using the existing SignalR resource change pattern

I threw in some suggested columns and status values in the mockup.

This should not change how commands run, scheduling, queue behavior, history, or download client processing. It is meant to be additive, a new entity, service, API endpoint, and Activity tab, with just a few small hook points into the existing search and download flow.

Describe alternatives you've considered

1. Extend CommandModel -Add tracking fields to the existing command system. Rejected since it would mess with shared command infrastructure and how long things are kept around.

2. Frontend only correlation via DownloadId - Store a CommandId in grab history and have the frontend stitch together Command, History, and Queue data. In reality command entries dont stick around long, so it wouldnt be a reliable way to track downloads or imports. Feels pretty fragile.

3. Event log with correlation IDs - Build a generic event log where each stage change is its own row, tied together with a correlation ID. More flexible for sure, but also more complex than what we need and introduces a new concept that doesnt really exist in the codebase today.

Right now the approach I like most is a new SearchActivity entity. It keeps things clean and separate and follows the same patterns Sonarr already uses with Queue and History having their own entity, service and controller.

Anything else?

Here are some related issues I found:

• #262 Task Queue
• #7992 Enhanced Visual Feedback in Queue
• #907 Separation of download checking and processing commands

Future stuff I purposely didnt include yet:

• Group rows by search command or download item
• Click through links to related Queue and History items
• Maybe include RSS or scheduled searches if that ends up being useful
• Missing or cutoff unmet search support

Mockup is attached to show roughly where this would live and what the table might look like.

Would love some feedback on the approach before I start building it out. Happy to open a draft PR early so people can see it and weigh in.