mirror of
https://github.com/jcreek/CosmicClash.git
synced 2026-09-10 16:04:04 +00:00
f6a87463c5
The candidate projection selected only from queue_tickets and its scan never set Candidate.Rating, so every PostgreSQL-sourced ranked candidate arrived with Go's zero value. Rating tolerance, selection scoring and team partitioning all read that field, so ranked matchmaking treated a 900-rated player as identical to a 2100-rated one. Unit tests missed it because they construct candidates with ratings already populated. Join the ratings table, defaulting to domain.GlickoInitialRating for a player with no ratings row yet -- a genuinely new profile, matching the column default. Fix the same defect on the Redis path too, which is reached differently: the projection is seeded from the candidate CreateQueueTicket builds, not from the candidate query, and that candidate also left Rating unset. Resolve the rating inside the enqueue transaction so both projections agree on one authoritative value. The rating is never client-supplied. Add a store-backed test with deliberately distant ratings (900 vs 2100) plus an unrated player, asserting both projections and that the spread survives. Verified it fails without the fix.