Skip to content

Merge development into main - #103

Merged
dangerworm merged 7 commits into
mainfrom
development
Jul 29, 2026
Merged

Merge development into main#103
dangerworm merged 7 commits into
mainfrom
development

Conversation

@dangerworm

Copy link
Copy Markdown
Owner

No description provided.

dangerworm and others added 5 commits July 28, 2026 23:14
RemoveQueueItemsAsync (both overloads) and RemoveInProgressItemsAsync batched deletes in a while-loop of O(rows / BulkUpdateSize) round trips. Program.cs clears the queue synchronously before Kestrel binds, so a large backlog (190k+ failed Weav3r items) made startup exceed the 230s Azure container startup probe -> container killed and restarted -> crash loop -> total API outage. Replace with a single set-based ExecuteDeleteAsync per method.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Dead code: no callers anywhere in the solution.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds a daily Hangfire job (PruneOldChangeLogs, 03:30 UTC) that deletes raw item_change_logs older than 30 days in oldest-first 1-day chunks (set-based ExecuteDeleteAsync per chunk, committed incrementally so a big first run is resumable). Raw logs are only read for history windows up to Week1 (7d); Month1+ history and the volatility/unusual-candidate rebuilds all read item_change_log_summaries, so 30 days is 4x the read need and the summaries carry the long-range history.

The cutoff is gated on the latest summarised bucket start (summarisedUpTo) so rows that haven't been rolled into summaries are never deleted; skips entirely if no summaries exist. Uses the existing ix_item_change_logs_change_time index.

TODO: one-time VACUUM FULL to reclaim disk after the first prune run (DELETE alone doesn't shrink the ~7.1G table).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 840b9c9297

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread api/TornTools.Persistence/Repositories/ItemChangeLogRepository.cs Outdated
dangerworm and others added 2 commits July 29, 2026 00:50
The default 30s Npgsql command timeout is fine for a steady-state daily prune (one chunk), but the first multi-month cleardown deletes a day at a time and a single high-traffic day can hold enough rows that the delete plus index maintenance exceeds 30s, wedging that chunk on every Hangfire retry. Raise the per-chunk command timeout to 5 minutes for the duration of the prune (mirrors the summariser's BuildSummariesAsync), restored in a finally. The change_time index (ix_item_change_logs_change_time, Flyway V1.12) already backs the range filter.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@dangerworm
dangerworm merged commit 10e6ee5 into main Jul 29, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant