[Szer]

Why

Aggregate snapshots (#518) are written lazily, so each heavy user's first load after a deploy still pays one full replay. That's the 4.56 s @fvnever span on the dashboard. 190 users with ≥20 events are still unsnapshotted in prod (31 with ≥100, 6 with ≥300, max 962).

What

• EventStore.RebuildSnapshot(fold, zero, policy, streamId): replays the whole log (ignoring any stored snapshot) and force-writes the snapshot when the stream has ≥ SnapshotEvery events. It works as both a backfill and a repair, e.g. of a wrong snapshot at the same version. It uses its own eventStore.snapshotRebuild span, and a failed write is recorded and swallowed like elsewhere.
• Vahter's existing permanent POST /rebuild-snapshots user phase already replayed every user stream; it now also writes the aggregate snapshot. No temporary endpoint, nothing to clean up.
• New ?scope=users runs only the user phase and skips the heavy message/moderation read-model pass. An unknown scope returns 400.

Tests (red → green)

• BotInfra: rebuild repairs a tampered snapshot at the same version (red against a stub that just called LoadState: 1000 vs 325); rebuild skips streams below SnapshotEvery.
• Vahter integration: POST /rebuild-snapshots?scope=users writes the aggregate snapshot for a 26-event user (correct User state) and doesn't build the message snapshot (red before: no snapshot row).
• Local: BotInfra.Tests 34/34, VahterBanBot.Unit.Tests 133/133, VahterBanBot.Tests 303/303.

After deploy

curl -X POST -H "X-Telegram-Bot-Api-Secret-Token: $BOT_AUTH_TOKEN" "https://vahter.szer.dev/rebuild-snapshots?scope=users"

🤖 Generated with Claude Code