fix(db): prune backups after health-check-repair snapshot - #13540
Closed
KooshaPari wants to merge 3 commits into
Closed
KooshaPari wants to merge 3 commits into
KooshaPari wants to merge 3 commits into
Conversation
added 3 commits
September 13, 2026 02:31
…bility (fixes diegosouzapw#13467) On macOS, Strategy 2 (ioreg IOPlatformUUID) resolves before Strategy 4 (os.hostname()), causing tests that mock os.hostname() to fail. - Add DISABLE_IOREG_STRATEGY env var check in machineId.ts Strategy 2 - Set env var in the test helper to skip ioreg on all platforms - Both tests now pass on macOS, Linux, and Windows
…ouzapw#13137) An eval case whose upstream call failed was graded as passed because the error string happened to match the expected pattern. Now when metrics.error is set, result.passed is forced to false so failed upstream calls never inflate the pass rate.
…osouzapw#13308) The managed backup path (VACUUM INTO) creates a full database snapshot on every startup but never calls the existing retention helper, causing db_backups/ to grow without bound. On one observed install this produced 10.3 GB across 18 snapshots in 8 days. Call cleanupDbBackups() after a successful snapshot so the operator's maxFiles / retentionDays settings apply uniformly to all backup paths. Dynamic import avoids a circular dependency with backup.ts.
Owner
diegosouzapw
pushed a commit
that referenced
this pull request
Sep 15, 2026
…13308) (#13404) Prunes `db_backups/` after the health-check-repair `VACUUM INTO` snapshot (#13308). That path never ran retention, so every restart of a healthy database added another full-size copy. It now uses the same `DB_BACKUP_MAX_FILES` / `DB_BACKUP_RETENTION_DAYS` limits as `backup.ts`, importing `backupRetention` directly to avoid the import cycle. Maintainer additions: merged the current release branch and rebaselined `src/lib/db/core.ts` 1745→1767 in `file-size-baseline.json` with a dated annotation (legitimate growth). Chosen over #13540, which did the same with a fire-and-forget dynamic import. Validated in one consolidated batch of this series (37 PRs boarded together on `release/v3.8.51`): `typecheck:core`, `check:open-sse-typecheck` and `check:dashboard-typecheck` clean; ESLint clean on every changed file; file-size, complexity, cognitive-complexity, changelog-integrity, docs-counts, docs-sync and migration-numbering gates green (only the pre-existing `open-sse/utils/stream.ts` file-size red remains, inherited from the base); 3,743 focused `node:test` cases plus 34 vitest cases green. Thanks @KooshaPari!
Bl0ck154
pushed a commit
to Bl0ck154/OmniRoute
that referenced
this pull request
Sep 20, 2026
…iegosouzapw#13308) (diegosouzapw#13404) Prunes `db_backups/` after the health-check-repair `VACUUM INTO` snapshot (diegosouzapw#13308). That path never ran retention, so every restart of a healthy database added another full-size copy. It now uses the same `DB_BACKUP_MAX_FILES` / `DB_BACKUP_RETENTION_DAYS` limits as `backup.ts`, importing `backupRetention` directly to avoid the import cycle. Maintainer additions: merged the current release branch and rebaselined `src/lib/db/core.ts` 1745→1767 in `file-size-baseline.json` with a dated annotation (legitimate growth). Chosen over diegosouzapw#13540, which did the same with a fire-and-forget dynamic import. Validated in one consolidated batch of this series (37 PRs boarded together on `release/v3.8.51`): `typecheck:core`, `check:open-sse-typecheck` and `check:dashboard-typecheck` clean; ESLint clean on every changed file; file-size, complexity, cognitive-complexity, changelog-integrity, docs-counts, docs-sync and migration-numbering gates green (only the pre-existing `open-sse/utils/stream.ts` file-size red remains, inherited from the base); 3,743 focused `node:test` cases plus 34 vitest cases green. Thanks @KooshaPari!
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…iegosouzapw#13308) (diegosouzapw#13404) Prunes `db_backups/` after the health-check-repair `VACUUM INTO` snapshot (diegosouzapw#13308). That path never ran retention, so every restart of a healthy database added another full-size copy. It now uses the same `DB_BACKUP_MAX_FILES` / `DB_BACKUP_RETENTION_DAYS` limits as `backup.ts`, importing `backupRetention` directly to avoid the import cycle. Maintainer additions: merged the current release branch and rebaselined `src/lib/db/core.ts` 1745→1767 in `file-size-baseline.json` with a dated annotation (legitimate growth). Chosen over diegosouzapw#13540, which did the same with a fire-and-forget dynamic import. Validated in one consolidated batch of this series (37 PRs boarded together on `release/v3.8.51`): `typecheck:core`, `check:open-sse-typecheck` and `check:dashboard-typecheck` clean; ESLint clean on every changed file; file-size, complexity, cognitive-complexity, changelog-integrity, docs-counts, docs-sync and migration-numbering gates green (only the pre-existing `open-sse/utils/stream.ts` file-size red remains, inherited from the base); 3,743 focused `node:test` cases plus 34 vitest cases green. Thanks @KooshaPari!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #13308
Problem
The health-check-repair backup path creates a full database snapshot via
VACUUM INTOon every startup but never calls the existing retention helper (cleanupDbBackups). This causesdb_backups/to grow without bound.On one observed install this produced 10.3 GB across 18 snapshots in 8 days, while the live database was 698 MB. A perfectly healthy database still produces a full copy on every startup.
Root cause
createManagedDbBackup()insrc/lib/db/core.tscreates the snapshot but has no pruning call after it. The regularbackupDbFile()path inbackup.tsdoes callcleanupDbBackups, but the health-check-repair path uses the separatecreateManagedDbBackupfunction which was missed.Fix
Call
cleanupDbBackups()after a successful snapshot increateManagedDbBackup, so the operator'smaxFiles/retentionDayssettings apply uniformly to all backup paths.A dynamic import of
./backupavoids a circular dependency (sincebackup.tsimports fromcore.ts).Changes
src/lib/db/core.ts: AddcleanupDbBackups()call afterVACUUM INTOincreateManagedDbBackup()Validation
cleanupDbBackupsis exported from./backupand accepts abackupDiroption.catch(() => {})ensures the backup still succeeds even if pruning fails