Development#91
Conversation
…volatility ranking
…into development
Prerequisite for the Unusual Activity pivot's multi-horizon z-score ranking — at 6h buckets the 1h and 6h analysis windows would both collapse to "last bucket" with no intraday resolution. Going to 1h directly rather than 2h so we don't have to re-bucket again later. Storage cost is ~1.2GB at 1-year retention, well within the B1ms 32GB budget; query cost is unchanged for the volatility rebuild because it still scans the same 30-day range, just with finer buckets, against the existing (item_id) and (bucket_start) indexes. V1.22 truncates item_change_log_summaries; the migration must ship with the SummaryBucketSeconds change because a 6h-constant app writing into a freshly-truncated 1h-intent table would silently produce 6h-aligned rows again. After deploy, SummariseChangeLogsAsync backfills from the earliest item_change_logs row (2025-11-19). First run is one-time long; subsequent runs are incremental. Manual trigger via /hangfire skips the 30-min wait. Top Movers widget keeps showing existing rankings (in item_volatility_stats) until the next 6-hourly rebuild kicks in with the new bucket data. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…xt instance documentation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b40a1cb5a4
ℹ️ 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".
| -- one-time long; subsequent runs are incremental. Trigger manually via | ||
| -- /hangfire to skip the 30-min wait. | ||
|
|
||
| TRUNCATE TABLE public.item_change_log_summaries; |
There was a problem hiding this comment.
Reset derived volatility stats after truncating summaries
V1.22 truncates item_change_log_summaries but does not clear item_volatility_stats, so right after migration the API can continue returning stale rankings computed from pre-migration data. This happens because RebuildStatsAsync only upserts rows found in the last 7 days of summaries; when the source table is empty (or still backfilling), it updates nothing, and GetTopAsync still reads the old rows. Please invalidate/truncate item_volatility_stats in the same migration (or gate reads by a fresh computed_at) so users don’t see outdated 6h-bucket results during/after cutover.
Useful? React with 👍 / 👎.
No description provided.