fix(settings): persist new settings defaults to disk on startup

[fallenbagel]

Description

Previously, when new default values were added to the Settings constructor, mergeSettings would correctly backfill them into memory at runtime, but save() was only triggered when apiKey, clientId, or vapidKeys were missing. This meant the file on disk would never be updated with the new defaults and every restart would silently re-merge the same missing keys, and the settings file would stay stale indefinitely.

This adds a check that compares the merged result against the file data after loading. If new keys were introduced from defaults, the file now gets written once on the first startup after an upgrade. Subsequent startups see no difference and skip the write.

This is the root cause behind several long-standing issues where settings appeared to not save properly, including series type not reflecting correctly, media server type not persisting, and other cases where newly introduced defaults were available in memory but never written to disk.

How Has This Been Tested?

(tested on #2731)

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

• Bug Fixes
  • Enhanced settings migration handling to ensure configuration changes are properly tracked and persisted during data updates.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 4ac6dbb3-81fc-43d7-b99c-535bfb930d5d

📥 Commits

Reviewing files that changed from the base of the PR and between 1cc73a8 and 935d7c9.

📒 Files selected for processing (1)

• server/lib/settings/index.ts

---

📝 Walkthrough

Walkthrough

The Settings.load method now tracks post-migration merge changes by introducing a change flag before migrations and updating it after merging to detect if the result differs from the migrated data. This enables conditional save triggering based on merge outcomes alongside existing key-generation logic.

Changes

Cohort / File(s)	Summary
Settings Migration Logic server/lib/settings/index.ts	Modified Settings.load to move change flag declaration before migrations and update its value after merge operations using JSON comparison, allowing downstream save triggering when merged data differs from migrated data.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• seerr-team/seerr#2696: Both PRs modify the settings migration+merge handling in Settings.load, with this PR focusing on post-merge change detection and the related PR replacing merge logic with mergeSettings function.

Suggested reviewers

• 0xSysR3ll
• gauthier-th

Poem

🐰 Hop, hop, migrations flow,
Flags now track what merge will show,
When settings shift, we'll know, we'll know,
And save the changes, off we go! ✨

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix(settings): persist new settings defaults to disk on startup' accurately and clearly describes the main change: ensuring that new default settings values are saved to disk when the application starts.

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

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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