2.8 KiB
Housekeeping rank synchronization
Behavior
Rank assignments commit the configured rank, user update, and audit intent before attempting emulator synchronization. Assignment and rank deletion acquire the configured-rank row lock first. Delivery acquires the user row lock, reads the current database rank, and holds that lock until the transport settles.
Retrying an old recovery reference therefore dispatches the current committed rank rather than replaying the rank stored in the old audit record. A user deleted after persistence produces an audited superseded result. SQL lock errors remain dependency failures rather than being reported as missing ranks.
The coordinated paths cover System operations, People user editing, the legacy command centre, legacy user editing, the user-actions API, legacy rank deletion, and shop rank upgrades. Administrative user creation also locks the selected rank. Shop upgrades compare the locked current rank so they cannot overwrite a newer staff promotion. A failed post-purchase rank delivery leaves a recovery intent without turning the completed purchase into another charge.
People and legacy responses preserve partial-completion information and recovery references. Failure of the completion audit alone does not misreport successful transport delivery as a transport failure.
Verification
- Focused rank, legacy-entrypoint, shop, System and People tests: 94 passed.
- Full suite: 280 files passed, 3 skipped; 1,861 tests passed, 5 skipped.
- Next.js 16.3.4 production build passed and generated all 245 pages.
- TypeScript and canonical Knip checks passed.
- Biome passed on all 13 changed source/test files.
- Project-source lint without formatting passed on 1,412 files, with one existing Catalog Studio warning. The full Windows checkout check also includes local untracked brainstorm HTML and reports CRLF/LF formatting differences; those local files were preserved and are not part of this change.
- Migration matrix: 138 historical rows valid; 138 legacy pages retained; runtime discovered/mapped/verified 138/138/138, with 2 intentional removals.
- Independent read-only review found no remaining Important or Critical issues.
Validation boundary
Tests exercise the parameterized locking SQL and controlled transaction/transport ordering. No live two-connection MariaDB race test or production emulator acceptance test was performed.
TCP RCON success means the socket write completed. CMS dispatch is serialized, but the current protocol does not acknowledge emulator processing or enforce its processing order. End-to-end confirmation would require an emulator protocol change. The existing transport timeout and retry policy bounds the delivery wait.
The PR remains draft; these checks are not a deployment or preview-cutover claim.