Repository navigation
v2.1.3 - #109
Merged
Merged
v2.1.3#109
Conversation
Storage management (requested by @db-can): - storage.delete/delete_prefix for local and R2 (batched at 1000 keys) - delete_session removes replay.json first, so an interrupted delete reads as "not downloaded" and reprocesses cleanly instead of half-removed - retention.py: policy stored in config/retention.json, applied on save and swept daily by its own task. Not in auto_precompute_loop, which only runs Fri-Mon and isn't started at all when AUTO_PRECOMPUTE=off - a delete tombstone stops auto-precompute re-downloading a removed session - evict_cached_session frees replay frames from memory on delete - Storage panel in the picker header; per-session delete on right-click Fixes: - docker-compose: container always listens on 8000 so reverse proxies have a stable target; PORT now sets the published host port only. 2.1.2 passed PORT into the container, moving the port Traefik/nginx/cloudflared target - replay websocket sends a keep-alive every 20s, and the client reconnects with backoff and resumes in place, so a dropped socket no longer freezes the UI permanently (#106) - replace the 50ms receive_text cancellation with a queue-fed reader task - clear the events cache after processing so downloaded markers appear immediately rather than after the 5 minute TTL Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add storage retention, fix reverse proxy port and replay freeze
A first sweep over a large backlog appeared to hang: delete_session made about five sequential R2 round trips per session, so deleting 134 sessions meant ~670 calls held open behind one request with nothing on screen. Measured against the bucket, 100 objects one at a time took 24.5s; the same 100 in bulk take 0.9s. - storage.keys_under lists once from the shared root; delete_keys removes exactly those keys in batches of 1000, reporting progress per batch - sweep uses them instead of per-session deletes, and skips tombstones: they exist to stop auto_precompute re-downloading a removed session, and it only looks at the last 7 days, which retention never touches - the sweep now runs in the background via start_sweep, with GET /api/storage/retention/status for progress, so the request no longer blocks and a refresh mid-delete doesn't lose it - the panel polls that status and shows a progress bar over files deleted - the retention controls stay hidden until usage has loaded, so a threshold can't be set against a total that hasn't arrived Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Make retention delete fast and show progress
This branch was successfully 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
1 participant
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.
2.1.3
Improvements
Fixes
Replay froze after a dropped connection — an idle replay sent no data, so proxies could close the socket and the client never reconnected. The server now sends a keep-alive every 20s, and the client reconnects and resumes where it left off. (#106, reported by @nbolland)
App unreachable behind a reverse proxy when
PORTwas set — 2.1.2 passedPORTinto the container, moving the port proxies point at (Traefik, nginx and cloudflared all target 8000). The container now always listens on 8000;PORTsets the published host port only. (found while investigating #106, reported by @nbolland)