fix(db): persist the Keep-latest-backups retention setting (#3834)

[diegosouzapw]

Closes #3834

Problem

In Settings → Database backup retention, changing "Keep latest backups" to anything other than 20 had no effect — it snapped back to 20 on refresh / after "Clean old backups". Editing .env was ignored too (Next does not reload process.env after start).

Root cause: getDbBackupMaxFiles() read only process.env.DB_BACKUP_MAX_FILES ?? 20. There was no setter and no persisted store, so the UI value was never saved. (A separate databaseSettings.backup.keepLastNBackups, default 5, exists but is never consumed by the cleanup logic — left untouched here to avoid surprising existing installs with a 5-backup default.)

Fix

• src/lib/db/backup.ts: getDbBackupMaxFiles() precedence is now env override → persisted value → default 20, backed by a dedicated key_value namespace (dbBackup/maxFiles). New setDbBackupMaxFiles() persists it. The dedicated namespace avoids cross-talk with the databaseSettings store (which rewrites all of its own keys on every update).
• src/app/api/db-backups/route.ts: the DELETE ("Clean old backups") handler persists the chosen keepLatest so it survives the subsequent loadStorageHealth() refetch.
• src/lib/localDb.ts: re-export setDbBackupMaxFiles (re-export only).

Existing installs keep the historical default of 20 until an operator explicitly changes it.

Tests (TDD)

tests/unit/db-backup-extended.test.ts: round-trip (set 5 → get 5 → set 12 → get 12), default-20-when-unset, and env-override-wins. The round-trip fails on the unfixed code (no setter; getter ignored any stored value). typecheck:core clean, lint 0 errors, file-size clean.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request implements persistence for the "Keep latest backups" database retention setting, resolving an issue where the setting would reset to 20 upon page refresh. The chosen value is now saved to a dedicated key_value store namespace (dbBackup) and retrieved with fallback precedence (env override → persisted value → default). Unit tests have been added to verify this behavior. Feedback on the changes suggests removing a redundant Number.parseInt call on a JSON-parsed number and wrapping the database write operation in a try/catch block to prevent potential write failures from crashing the cleanup process.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The JSON.parse(row.value) call already returns a parsed number since the value was stored using JSON.stringify(value) where value is a number. Wrapping it in Number.parseInt(..., 10) is redundant and can be safely removed.

Suggested change

	const parsed = Number.parseInt(JSON.parse(row.value), 10);
	const parsed = JSON.parse(row.value);

[gemini-code-assist]

Database write operations can fail due to various reasons (e.g., database locked, read-only database, or disk full). Since persisting this setting is a non-critical side effect of the backup cleanup process, wrapping the database write in a try/catch block ensures that a write failure does not crash the entire cleanup operation.

Suggested change

	const db = getDbInstance();
	db.prepare(
	"INSERT OR REPLACE INTO key_value (namespace, key, value) VALUES (?, ?, ?)"
	).run(DB_BACKUP_SETTINGS_NAMESPACE, DB_BACKUP_MAX_FILES_KEY, JSON.stringify(value));
	try {
	const db = getDbInstance();
	db.prepare(
	"INSERT OR REPLACE INTO key_value (namespace, key, value) VALUES (?, ?, ?)"
	).run(DB_BACKUP_SETTINGS_NAMESPACE, DB_BACKUP_MAX_FILES_KEY, JSON.stringify(value));
	} catch (error) {
	console.error("Failed to persist DB backup max files setting:", error);
	}