1a216dc79521e0726090d8135bcd9e01df525084
The game is getting a crazy mode that drops extra balls, and scores
reached with it should still enter the shared table but be visibly
labelled. The service therefore has to persist and return that label.
API:
- POST /api/highscores accepts an optional "crazy" boolean. Missing
means false, so cached clients from before crazy mode keep working.
- GET responses include "crazy" on every entry. Older clients ignore
unknown fields (serde default behaviour), so the new response shape is
safe for them too.
Database:
- New databases get a `crazy INTEGER NOT NULL DEFAULT 0 CHECK (crazy IN
(0, 1))` column.
- Existing databases are migrated on open: if pragma_table_info shows no
`crazy` column, ALTER TABLE adds it with the same definition. SQLite
fills existing rows with the default, so every historic score stays a
normal score. No data is rewritten and the migration is idempotent.
Ordering and the top-ten pruning are unchanged; the flag is not part of
the ranking.
Test Plan:
- cargo test --manifest-path highscore-server/Cargo.toml
- pre_crazy_mode_database_is_migrated_in_place: builds the old schema
with a row, opens it, submits a crazy score, checks both rows come
back with the right flag, and reopens the migrated file.
- api_accepts_crazy_flag_and_defaults_it_for_old_clients: one request
without the field, one with "crazy": true.
- Deploy: restart the service against the production database and check
GET /api/highscores lists the old entries with "crazy": false.
Languages
C
73.2%
Rust
14.6%
C++
5%
Python
4.1%
Shell
1.4%
Other
1.6%