The leaderboard that only half-worked, on purpose by accident

Shortly after Steam leaderboards went in, a report: total-score entries were showing up fine, but the endless-best-wave board stayed completely empty — across multiple confirmed deaths, on an account where Steam was clearly connected and working (the leaderboards menu button was visible, and the OTHER board was receiving entries from the same account).

First step was ruling out the boring explanation. We added a diagnostic endpoint to the relay Worker to check the board IDs directly, and both resolved correctly. So it wasn't a config typo or a wrong app ID — something was failing specifically on the client, and specifically for one board.

Two bugs, both hiding behind "submitted first"

The code submitted both boards in the same function, back to back, with no await between them. That's the whole story, once you know what getAuthTicketForWebApi() does under the hood:

Each submission mints its own auth ticket and cancels it in a finally block when done. Fire two of those at once against a single Steam identity and you get two tickets in flight — and the first one can get cancelled before the Worker has even finished verifying it. Whichever board submitted first was the one that lost the race.
Separately, the code marked a board as "already sent" the moment it decided to send it — not after confirming it actually landed. So a submission that failed silently marked itself as done, and would never be retried for the rest of that session.

Both bugs point at the same board for the same reason: whichever submission goes first is uniquely exposed to a race it doesn't know it's in, and gets marked as successful regardless of what actually happened. Two independent mistakes, stacked so they'd always blame the same victim.

The fix serializes the two submissions — one live ticket at a time, no more racing cancellations — and only marks a board as sent after its promise actually resolves successfully. A failed submit now just quietly retries on the next run's end instead of being permanently written off.

We verified the logic fix by extracting and re-running the submission code directly: peak concurrent submissions dropped from 2 to 1, a simulated failure gets retried on the next call, and a real success still correctly avoids re-submitting the same value. The one thing we couldn't verify without a live Steam-connected build is the actual end-to-end round trip — that's the honest kind of "should be fixed" that only a real death in a real build can close out.