Radarr/Sonarr apiKey sent empty on background jobs (?apikey=), and gets wiped from settings.json when the 0007_migrate_arr_tags migration fails

[ndoty]

A tcpdump capture of the actual outgoing request from the Seerr container to Radarr shows:

GET /api/v3/movie?apikey= HTTP/1.1
Content-Type: application/json
User-Agent: axios/1.15.0
Host: radarr:7878

The apikey query parameter is present but empty -- no value, and no X-Api-Key header is sent either. A temporary debug log inserted at ServarrBase's constructor (server/api/servarr/base.ts) confirmed the apiKey argument itself is "" (empty string, not undefined) at the moment RadarrAPI/SonarrAPI is instantiated, both from the scheduled scan job (server/lib/scanners/radarr/index.ts) and from the 0007_migrate_arr_tags migration (server/lib/settings/migrations/0007_migrate_arr_tags.ts).

Tracing further back, radarr[0].apiKey in the actual settings.json on disk was itself empty -- despite having just been set correctly via PUT /api/v1/settings/radarr/0 moments earlier (verified immediately after the PUT, and again immediately after a fresh container restart). The value became empty specifically in connection with the 0007_migrate_arr_tags migration failing partway through (it never marks itself complete in settings.migrations when errorOccurred is true, so it re-runs on every boot) -- but a clean repro after re-setting the key and letting that migration succeed did not reproduce the corruption again, so I wasn't able to pin the exact line responsible in the time I had. Worth noting 0007_migrate_arr_tags.ts reads radarrSettings.apiKey/sonarrSettings.apiKey directly off the raw settings object passed into runMigrations, before mergeSettings -- if that raw object is ever partially constructed (e.g. mid-write, or from a stale in-memory reference during the Overseerr->Seerr conversion), this migration would be the first thing to observe and log the resulting failure, which matches what I saw.

Environment

• Seerr version: 3.4.1 (commit 69f73a6f1486fdb51b8ddae9a94a8dfb629f461c)
• Docker image: seerr/seerr:latest
• Migrated from: Overseerr (sctx/overseerr:latest, last build 2026-02-15)
• Radarr: 6.3.0.10514, Sonarr: comparable recent version
• Deployment: docker compose, Radarr/Sonarr reached via internal Docker network hostnames (not a proxy)

Steps to reproduce

1. Configure a Radarr/Sonarr instance in Seerr with a valid API key and tagRequests enabled.
2. Trigger the "Radarr Scan" / "Sonarr Scan" job (or restart the container so 0007_migrate_arr_tags runs).
3. Observe 401 Unauthorized / Failed to retrieve movies in the Seerr logs despite the key being correct.
4. (Optional) Confirm via packet capture that the outgoing request's apikey param is empty.

Impact: Radarr/Sonarr library sync, tag migration, and download-queue tracking are broken, while the underlying Plex/media-request functionality is unaffected. Manual "Test" style calls that construct a fresh request from current settings appear unaffected -- this seems isolated to the specific code paths above.

[github-actions]

Possible duplicate detected

This issue may be a duplicate of the following (detected via semantic similarity + LLM review):

• Requests created during a Radarr/Sonarr scan are declined as orphaned - scan-end cleanup compares fresh DB state against the scan-start snapshot (not an API timeout, re #3347) #3373 (63% match) — Requests created during a Radarr/Sonarr scan are declined as orphaned - scan-end cleanup compares fresh DB state against the scan-start snapshot (not an API timeout, re Auto-approved requests declined during Radarr scan #3347)
• Anime requests fail with "Quality Profile does not exist" when activeAnimeProfileId is stale #3159 (59% match) — Anime requests fail with "Quality Profile does not exist" when activeAnimeProfileId is stale
• Radarr Scan permanently exhausts the Postgres connection pool on 3.4.x (regression from 3.3.0) #3363 (57% match) — Radarr Scan permanently exhausts the Postgres connection pool on 3.4.x (regression from 3.3.0)

A maintainer will review this. If this is not a duplicate, no action is needed.

[gauthier-th]

As written in our contributing guide:

Submissions that appear to be unreviewed AI output will be considered low-effort and may result in a ban if repeated even after several warnings. Signs of unreviewed AI output include but are not limited to:

• Blank or template-default PR descriptions
• AI-generated PR descriptions that replace our template with their own structure (e.g., "Summary / What changed / Root cause / Test plan" instead of following the PR template; this is the default output format of tools like Claude Code and is an immediate indicator that the PR was not reviewed by a human)

This also seems to be wrong, since this migration only reads the API key and never writes it.

For future troubleshooting, use the appropriated support channel.