Repository navigation
Conversation
Every full publish stores each page's bundled runtime files in published_runtime_assets under a fresh version path, and nothing ever deleted them. On a busy production site the table reached 206k rows / 1.5 GB (696 MB written in one day), bloating the database and its backups for bytes that are only a fallback behind the disk-baked copies. persistSitePublish now deletes, per page, the stored assets of every version other than the one being activated and the one it supersedes. Nothing re-activates an old version, and keeping the previous one covers visitors still holding its HTML — the same window the disk's two-slot swap covers. Version rows are untouched. The first publish after upgrading drops the backlog for the published pages. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ngocht
marked this pull request as ready for review
October 14, 2026 18:12
This branch has not been deployed
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.
Summary
Every full publish stores each page's bundled runtime files in
published_runtime_assetsunder a fresh version path, and nothing ever deleted them. On a busy production site the table reached 206k rows / 1.5 GB of a 2 GB database. One day of editing wrote 696 MB (about 19 files / 310 KB per page version). These bytes are only a fallback behind the disk-baked copies (tryServeRuntimeAssetis disk-first), but they bloat the database and every backup.Change:
persistSitePublishnow deletes, per page, the stored assets of every version other than the one being activated and the one it supersedes.active_version_idis only ever set to the version being published.site_snapshots) are untouched.VACUUM FULL published_runtime_assets(Postgres) orVACUUM(SQLite).Not in scope:
site_snapshotsalso grow by one full site document per publish. Pruning them needs a version-history retention decision.Verification
bun run build— rantsc -p tsconfig.app.jsonandtsc -p tsconfig.node.json(clean)bun test— ranbun test src/__tests__/server/: 1115 pass. NewpublishRuntimeAssetRetention.test.ts(real SQLite viacreateTestDb): after four publishes only the last two versions per page keep assets and all version rows remain; fails onmain. ThecmsPublishfake DB handles the two new queries.bun run lint— eslint on the changed files (clean)Checklist
🤖 Generated with Claude Code