Checkpoint: How Sonarr Decides Before It Grabs
Sonarr's pre-grab decision becomes clear only when its earlier ideas are connected. This checkpoint follows one candidate through canonical episode state, parsed identity, indexer discovery, policy gates, and prioritization, then uses that trace to diagnose three outcomes: approved, temporarily pending, and permanently rejected. The reader's task is not to memorize another rule. It is to locate the state or evidence that caused the outcome.
The scenario is ordinary. A reader has a series in Sonarr, one episode is in scope, and an indexer reports a release. The report is not yet a download. Between the report and any external action lie several boundaries, each owned by a different part of the system. If those boundaries are collapsed, a missing file can be blamed on the wrong subsystem and a safe refusal can look like a failure.
Start with the episode Sonarr is trying to maintain
The trace begins with the durable series and episode model. Sonarr knows which series the episode belongs to, how the episode is numbered or dated, whether it is monitored, and which quality profile is associated with the series. The episode may or may not have a linked file. That absence is the reason a candidate is relevant, but it is not permission to accept every release that appears.
This initial state answers the first diagnostic question: what is the desired library state? If the episode is outside the current monitoring choice, a release can be perfectly real and still irrelevant to automatic maintenance. If the episode is monitored and has no linked file, Sonarr has a reason to consider candidates. If it already has a file, the question changes from “can this fill a gap?” to “would this improve or replace what is already present?”
The series record also supplies identity context. Titles, normalized forms, external identifiers, dates, series type, and other metadata give later parsing results something stable to be compared with. A release name is not judged in a vacuum. The same visible title or number can mean different things depending on which series and episode records exist in the local database.
The quality profile provides another local reference. It contains an ordered set of qualities, a cutoff, upgrade settings, and custom-format scoring rules. Those choices do not describe what the indexer claims. They describe how this library evaluates a candidate. This is the first place where the same release can produce different decisions for different series or different installations.
Turn the release string into evidence
The indexer report supplies an external candidate. Sonarr's parser interprets its title and produces structured information: a possible series title, season and episode numbers, absolute numbers where relevant, an air date, release type, quality, languages, release group, hash, and remaining release tokens. The parser can recognize standard, daily, anime, special, season-pack, partial-season, and multi-episode forms, but it does not turn every match into a confirmed library identity.
That distinction is the second diagnostic question: what does the text establish, and what is still a hypothesis? A familiar series title and episode marker may be enough to create a mapping candidate.