HIGH SCORES click-through causes "LOADING…" state + highscore-not-stored (extends #135) #141

New issue

Closed

opened 2026-06-24 00:55:46 +02:00 by bosun · 0 comments

bosun commented

2026-06-24 00:55:46 +02:00

Owner

Behavior (operator playtest 2026-06-24 against v1.0.0)

Extension of #135 (desktop click-through on HIGH SCORES overlay) — the click-through has a data-loss consequence that wasn't in original scope:

From title, press L → HIGH SCORES overlay opens
Click through the overlay where SOLO sits behind → solo game runs normally (this is #135's behavior)
After aborting the solo game (Esc twice) → return to title
HIGH SCORES screen displays "LOADING..." indefinitely
Closing with L or Esc works
Any highscore reached in such a game is NOT stored
Repeating produces same "LOADING..." state regardless of actual score

Severity: MED — data-loss

#135 was LOW (visual click-through). This finding extends to data-loss: scores from games started via click-through never persist. Substantive enough to address before #135's mechanism-fix (capture-click-on-overlay-when-active).

Likely root cause area

The click-through bypasses the overlay-active state-transition; subsequent gameplay enters a partially-initialized state where the leaderboard-write path is broken AND the leaderboard display path stays in "LOADING..." (probably leaderboard-fetch raced the click-through state, didn't complete, and the state-machine doesn't recover).

Fix-direction

Fixing #135 (overlay swallows all clicks when active) prevents the entry condition entirely. The data-loss-on-click-through becomes moot. So this tracker could close-as-duplicate-of-#135 once #135 is fixed — but the severity escalates priority for #135.

Alternative: also fix the partially-initialized state recovery (defense-in-depth) if entered via any path.

Cross-refs

cellblock#135 (parent — visual click-through; this finding extends to data-loss consequence)

Anchor

2026-06-24 operator playtest of v1.0.0 release.

## Behavior (operator playtest 2026-06-24 against v1.0.0) Extension of #135 (desktop click-through on HIGH SCORES overlay) — the click-through has a **data-loss consequence** that wasn't in original scope: 1. From title, press `L` → HIGH SCORES overlay opens 2. Click through the overlay where SOLO sits behind → solo game runs normally (this is #135's behavior) 3. After aborting the solo game (Esc twice) → return to title 4. HIGH SCORES screen displays "LOADING..." indefinitely 5. Closing with `L` or `Esc` works 6. **Any highscore reached in such a game is NOT stored** 7. Repeating produces same "LOADING..." state regardless of actual score ## Severity: MED — data-loss #135 was LOW (visual click-through). This finding extends to data-loss: scores from games started via click-through never persist. Substantive enough to address before #135's mechanism-fix (capture-click-on-overlay-when-active). ## Likely root cause area The click-through bypasses the overlay-active state-transition; subsequent gameplay enters a partially-initialized state where the leaderboard-write path is broken AND the leaderboard display path stays in "LOADING..." (probably leaderboard-fetch raced the click-through state, didn't complete, and the state-machine doesn't recover). ## Fix-direction Fixing #135 (overlay swallows all clicks when active) prevents the entry condition entirely. The data-loss-on-click-through becomes moot. So this tracker **could close-as-duplicate-of-#135** once #135 is fixed — but the severity escalates priority for #135. Alternative: also fix the partially-initialized state recovery (defense-in-depth) if entered via any path. ## Cross-refs - cellblock#135 (parent — visual click-through; this finding extends to data-loss consequence) ## Anchor 2026-06-24 operator playtest of v1.0.0 release.