feat(arr): outbound Sonarr/Radarr client with classified failures + Test Connection (#4)

[ChrisonSimtian]

PR 2 of 3 for #4. Implements IArrClient against the *arr v3 API (GET /api/v3/system/status, X-Api-Key header) plus the Action that drives it from the UI.

Failures are classified, not just reported

That's the whole point of this client. "It doesn't work" is the most common self-hosting complaint, and only a specific cause is actionable — a wrong port looks nothing like a wrong API key, and a reverse-proxy subpath omitted from the base URL looks nothing like either.

Cause	Detected from	Message points at
Unauthorized	401 / 403	the API key
ApiNotFound	404	a missing reverse-proxy subpath
NotAnArrInstance	200 with no appName/version, or not JSON	the port
TlsFailure	AuthenticationException anywhere in the chain	self-signed / expired cert
Unreachable	SocketException, or timeout	host and port
Unexpected	anything else	never silently treated as success

Three details worth a look

Base URLs keep their subpath. Instances behind a reverse proxy are commonly served from https://host/sonarr, and Uri's relative resolution drops the last segment unless the base ends in a slash. Without handling that, /sonarr/api/v3/status silently becomes /api/v3/status — producing a 404 that looks like a wrong path when the config was actually fine. Asserted both ways.

The API key goes in the header, not the query string, so it never lands in a proxy access log. There's a test asserting the key does not appear in the URI.

Timeout is 10s, not HttpClient's 100s default. This sits behind an operator clicking Test, so a hung connection must fail fast rather than leave the button spinning for a minute and a half.

The Action

TestArrConnectionHandler caches the outcome on the instance, so the settings page renders state without re-probing everything on load. It has an overload for unsaved details — so a wrong key never has to be persisted just to discover it's wrong.

Caller cancellation propagates rather than being recorded as an instance failure: a cancelled page load is not a broken Sonarr, and caching it as one would be actively misleading.

This is an Action running in a UI host — the deliberate, narrow DR-009 deviation recorded in the plan. The operator clicks a button and expects an answer; round-tripping "test this instance" through the durable bus to an agent and polling for a result is far more machinery than a button warrants.

Testing

Against a stubbed HttpMessageHandler, not a live test — Live.Tests hits real broadcasters and there's no real Sonarr to point at. Covers every failure mode above, plus subpath preservation, trailing-slash handling, header placement, malformed base URLs failing without leaving the process, and cancellation propagation.

Tests: App 71 / Arch 11 / Infra 102 green, 0 warnings.

Also

Points the plan's plaintext-key note at #60, filed to replace plaintext *arr key storage with encryption at rest. Worth noting the real question there is key management, not the cipher — and that encryption at rest protects database dumps and stolen volumes, not a compromised app host, since the app must be able to decrypt.

Next

PR 3 — the /settings page: instance CRUD with a per-row Test button, plus the download settings whose GetSettings/SaveSettings handlers are registered in DI but called by nothing.

Plan: docs/plans/2026-07-27 - arr-instance-config-ui.md

🤖 Generated with Claude Code