Skip to content

Enable map counting workers with two grouped SQL statements - #22

Merged
needs merged 1 commit into
masterfrom
map-count-workers
Aug 13, 2026
Merged

Enable map counting workers with two grouped SQL statements#22
needs merged 1 commit into
masterfrom
map-count-workers

Conversation

@needs

@needs needs commented Aug 13, 2026

Copy link
Copy Markdown
Owner

The map counting workers were never enabled because one BullMQ job per map (~95k maps, three queries each) was too expensive. This replaces the per-map fan-out with two typedSql statements that update all map counters at once and skip rows whose counts are unchanged. A daily full job recomputes playerCount/clanCount/gameServerCount in one grouped pass (measured ~160s against the production database, read-only), and an hourly gameServers job refreshes only gameServerCount from the 911-row GameServerState table (measured 67ms). The map-count queue now carries a mode field with per-mode deduplication, mapScheduler() is wired into the scheduler, and the unused UPDATE_MAPS_COUNTS_CONCURRENCY env var is dropped. Verified on a local dev database (616/621 stale maps populated, second run writes 0 rows) and status-page exports are unchanged.

🤖 Generated with Claude Code

Replace the never-enabled per-map count jobs (one BullMQ job per map,
three queries each) with a single map-count job running one grouped
UPDATE. The full recompute of playerCount/clanCount/gameServerCount
scans PlayerInfoMap and ClanInfoMap once (~160s in production) and runs
daily; a gameServerCount-only refresh (67ms) runs hourly. Both skip
rows whose counts are unchanged.

Co-Authored-By: Claude Fable 5 <[email protected]>
@needs
needs merged commit 680f3be into master Aug 13, 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