feat(servarr-api): make Servarr API request timeout configurable

[fallenbagel]

Description

Adds a configurable API request timeout setting under Network Settings, replacing the previously hardcoded timeout in Servarr API calls. Users experiencing timeout errors when communicating with Radarr/Sonarr can now adjust the timeout to suit their environment. The value is displayed in seconds in the UI and defaults to 10 seconds (which was set previously in #2442), with 0 disabling the timeout entirely. Requires a restart to take effect.

• Fixes Radarr timeout too quick - "Failed to add movie to Radarr" #2555

How Has This Been Tested?

Screenshots / Logs (if applicable)

Checklist:

• I have read and followed the contribution guidelines.
• Disclosed any use of AI (see our policy)
• I have updated the documentation accordingly.
• All new and existing tests passed.
• Successful build pnpm build
• Translation keys pnpm i18n:extract
• Database migration (if required)

Summary by CodeRabbit

• New Features
  • Added configurable "API Request Timeout" to Network settings with validation and translations.
  • Default timeout set to 10 seconds (0 = no timeout); UI shows helper tip and restart-required badge.
  • External service requests (e.g., Radarr/Sonarr) now respect the configured API request timeout.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

Servarr integrations (ServarrBase, RadarrAPI, SonarrAPI) now derive the HTTP request timeout at runtime from settings; the settings system and UI gained a configurable apiRequestTimeout (seconds → ms) value persisted in NetworkSettings.

Changes

Cohort / File(s)	Summary
Servarr API Base Class server/api/servarr/base.ts	Replaced type-only import with getSettings; removed caller-provided timeout param from constructor and now computes timeout = getSettings().network.apiRequestTimeout and passes it to super(...).
Servarr API Implementations server/api/servarr/radarr.ts, server/api/servarr/sonarr.ts	Removed optional timeout from RadarrAPI and SonarrAPI constructors and stopped forwarding a timeout value to the base class.
Settings Backend server/lib/settings/index.ts	Added apiRequestTimeout: number to NetworkSettings and initialized default (10000 ms).
Settings UI src/components/Settings/SettingsNetwork/index.tsx	Added apiRequestTimeout form field, Yup validation (required, number, min 0), UI rendering, unit conversion (seconds ↔ milliseconds) and included value in POST payload.
i18n src/i18n/locale/en.json	Added translation keys for apiRequestTimeout, apiRequestTimeoutTip, and validationApiRequestTimeout.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant UI as Settings UI
    participant API as Settings API
    participant DB as Settings Store
    participant ServarrBase
    participant External as Radarr/Sonarr

    User->>UI: update apiRequestTimeout (seconds)
    UI->>API: POST network settings (apiRequestTimeout ms)
    API->>DB: persist NetworkSettings.apiRequestTimeout
    Note right of DB: value stored (ms)
    ServarrBase->>API: getSettings() when constructing/initializing
    API->>DB: read NetworkSettings
    DB-->>API: return settings (apiRequestTimeout ms)
    API-->>ServarrBase: settings object
    ServarrBase->>External: send request (timeout = apiRequestTimeout ms)
    External-->>ServarrBase: response / timeout error

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• fix(servarr): increase default API timeout from 5000ms to 10000ms #2442: Modifies ServarrBase timeout behavior; changes default timeout value while this PR changes sourcing to runtime settings.

Suggested reviewers

• gauthier-th
• 0xSysR3ll
• M0NsTeRRR

Poem

🐰
I fiddled with timeouts, hopped through the code,
Now settings decide how long requests may go.
No more quick failures, just patience and cheer,
Radarr and Sonarr can take a bit more time here. 🥕✨

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: making Servarr API request timeout configurable, which is the primary objective of this pull request.
Linked Issues check	✅ Passed	All code changes directly address issue #2555 objectives: making API request timeout user-configurable via UI settings, allowing users to adjust it based on their environment, and preventing premature request failures.
Out of Scope Changes check	✅ Passed	All changes are in-scope and directly contribute to the configurable timeout feature: settings interface updates, backend timeout derivation, UI settings form, validation, internationalization, and removal of hardcoded timeout parameters.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/components/Settings/SettingsNetwork/index.tsx`:
- Around line 141-143: The initialization for apiRequestTimeout currently uses a
truthy check that treats 0 as falsy and falls back to 10; change the check in
the SettingsNetwork initial values so it preserves an explicit 0 by using a
nullish/undefined check (e.g., test data?.apiRequestTimeout !== undefined or use
the nullish coalescing operator) when setting apiRequestTimeout in the component
(the expression referencing data?.apiRequestTimeout should be updated) so a zero
timeout remains 0 instead of resetting to 10.

[Copilot]

Pull request overview

This PR adds a configurable API request timeout setting for Servarr (Radarr/Sonarr) API calls to address timeout issues users were experiencing, particularly when these services are under load or accessing network-mounted storage. The timeout is now configurable through the Network Settings UI instead of being hardcoded, with a default of 10 seconds and the option to disable it entirely by setting it to 0.

Changes:

• Added configurable API request timeout setting in Network Settings with UI display in seconds
• Refactored ServarrBase constructor to retrieve timeout from settings instead of accepting it as a parameter
• Updated locale strings to support the new setting

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/i18n/locale/en.json	Added translation keys for API request timeout setting and validation messages
src/components/Settings/SettingsNetwork/index.tsx	Added form field, validation schema, and initial value handling for apiRequestTimeout with seconds-to-milliseconds conversion
server/lib/settings/index.ts	Added apiRequestTimeout property to NetworkSettings interface with 10000ms default
server/api/servarr/base.ts	Modified constructor to retrieve timeout from global settings instead of accepting as parameter
server/api/servarr/radarr.ts	Simplified constructor signature by removing optional timeout parameter
server/api/servarr/sonarr.ts	Simplified constructor signature by removing optional timeout parameter

Comments suppressed due to low confidence (2)

src/components/Settings/SettingsNetwork/index.tsx:101

• The validation schema is missing an integer constraint on apiRequestTimeout. Unlike the proxyPort validation (lines 92-96), this allows decimal values which would be converted to milliseconds incorrectly. For example, entering 10.5 seconds would be saved as 10500ms, which might confuse users. Add .integer() after .typeError() to ensure only whole numbers are accepted.

    apiRequestTimeout: Yup.number()
      .typeError(intl.formatMessage(messages.validationApiRequestTimeout))
      .required(intl.formatMessage(messages.validationApiRequestTimeout))
      .min(0, intl.formatMessage(messages.validationApiRequestTimeout)),

src/components/Settings/SettingsNetwork/index.tsx:101

• The validation schema lacks a maximum value constraint for apiRequestTimeout. Without an upper bound, users could set extremely large values (e.g., 999999 seconds = ~11.5 days) which would effectively disable timeout protection and could cause the application to hang indefinitely. Consider adding a reasonable maximum value like .max(300) for 5 minutes, or .max(600) for 10 minutes, similar to how proxyPort has .max(65535).

    apiRequestTimeout: Yup.number()
      .typeError(intl.formatMessage(messages.validationApiRequestTimeout))
      .required(intl.formatMessage(messages.validationApiRequestTimeout))
      .min(0, intl.formatMessage(messages.validationApiRequestTimeout)),

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[0xSysR3ll]

LGTM

[gauthier-th]

Success!