$>g__EnsureSplitTestHardOverrides|0_32(RecDBContext dbContext) in Program.cs:line 1162 at Program.<

$>g__EnsureRequiredGameConfigs|0_31(RecDBContext dbContext) in Program.cs:line 1137 at Program.

$(String[] args) in Program.cs:line 427 The mechanism is a single rule of EF Core being ignored in four places: **a row this DbContext has added is not in the database yet, so a query for its key answers null.** 1. `EnsureRequiredGameConfigs` upserts `splitTestHardOverrides` - `UpsertGameConfigValue` queries, sees nothing (empty database), and *adds* a `ConfigVal`. Tracked, unsaved. 2. Two lines later `EnsureSplitTestHardOverrides` queries for the same key, again sees nothing against the database, and adds a second instance of it. EF refuses the moment the duplicate is tracked - and the process dies before the `SaveChangesAsync` at the end of the method that would have made the first row visible. That last detail is what made it unrecoverable rather than a one-off: nothing was persisted, so **every** subsequent start walked into the same conflict. Three more keys were armed the same way behind it - `splitTestsAvailable` and `splitTestSegmentProbabilities` (`RepairSplitTestConfigs`, line 430) and the `UGC.Room2*` batch (`EnableBetaCreativeToolsConfigs`). The fix is `Server/Utils/GameConfigSeeder.cs`: one lookup that checks `dbContext.GameConfig.Local` (the tracked rows, including unsaved adds) before the database, plus the upsert built on it. All four find-or-add sites go through it now, with the tracked-aware trick `EnsureReferenceGameConfigs` already used for its own keys. `ServerTests/GameConfigSeederTests.cs` pins it, including the conflict itself as a case: add a row, query for it, watch the query answer null, then watch the second add throw. Nothing else was wrong - the wipe regenerated the schema, the Coach profile, the config, the default rooms and the dorm, and only this seeding step was unpassable. Anyone stuck on a build without the fix can seed the three keys by hand and get up: ```sql USE RadicadeServer; INSERT INTO GameConfig ([Key],[Value]) VALUES ('splitTestHardOverrides',''), ('splitTestsAvailable',''), ('splitTestSegmentProbabilities',''); ``` Both lookups then find a row in the database and neither adds anything; the blank values are filled in by the upsert and `RepairSplitTestConfigs` on the same start. ## 2026-10-01 18:30 - the game-update alert has no notification to send, so the client plays it Sending a Game Update from the panel stored a row, pushed a frame, and made no sound. The hub log is specific about how far it got: ``` [Realtime] Notification #39 Id=27 IdToken=String Msg={} <- arrived, parsed [Realtime] 27 envelope: {"Id":"27","Msg":{}} <- the frame, echoed [Realtime] the client called IPCPDNFCGPA("{...}") <- no handler registered under "27" ``` `IdToken=String` rules out the old parse failure (`expected:'String Begin Token'`), and the third line is the client falling past every registered handler into its channel/lookup path. The id was never going to match, for a reason worth writing down: **this client has no notification for a game update at all.** Its enum, read out of `RecNet.Runtime.dll` metadata (40 members), runs `24 ModerationRoomBan`, `25 ServerMaintenance`, `30 GiftPackageReceived` - there is no 26, no 27, and `AnnouncementGameUpdate` appears nowhere in that assembly as a string, while `ServerMaintenance`, `ModerationKick`, `ChatMessageReceived` and `PresenceHeartbeatResponse` all do. So neither spelling can work: the number matches nothing, and the name has no handler to register. `AnnouncementText` (26) is equally phantom, which is the standing explanation for why regular announcements only ever reach a player through the REST fetch and never through a push. That matches how Rec Room's own alert works: the sound is a client-side asset with nothing behind it on the wire, and the server can only ever *request* it. So the request is the frame the panel already produces, and the playing is now the client's own job - `2023Patch/RadicadeSeptemberClient/AnnouncementSoundAlert.cs`: * it hooks `WebSocketTransport.OnMessage` (the same raw-frame hook `RealtimeDiagnostics` already uses) and reads the record properly - `target == Notification`, the envelope out of `arguments[0]`, then its `Id` - rather than by substring, so a payload that merely mentions an id cannot set it off; * ids `"27"`, `"AnnounceNewUpdate"` and `"RadicadeAnnounceNewUpdate"` all mean "play it", so moving the server to an explicit marker later needs no new client build; * the sound is embedded in the DLL (`Assets/AnnounceNewUpdate.wav`, 16-bit stereo 44.1kHz, ~7.6s) and played through a 2D `AudioSource` on a `DontDestroyOnLoad` object - 2D because the alert is not a position in the world and must not be attenuated by wherever the player is standing; * Unity audio is main-thread only and a notify frame can arrive on BestHTTP's receive thread, so the play is handed to the captured main-thread synchronisation context and refuses to run (loudly) anywhere else rather than asserting inside the game; * `Alert.TestOnStartup` is **off by default** and exists only to prove the DLL can play a sound with no server involved: turned on, it plays the alert once, by itself, a few seconds after the game's audio is up. A client must never make a noise on its own when somebody just launches the game - which is exactly what the first build did, three times over. The loop only checked *after* posting, so ticks that queued while the game was still booting each played (log: `play #1`, `#2`, `#3` on one launch). The play is now claimed by the first probe that finds an audio listener, so the extra ticks do nothing. `Alert.SoundFile` swaps in another wav; `Alert.Volume` and `Alert.Enabled` do what they say. * the clip is held on the source (`AudioSource.clip`) as well as played with `PlayOneShot`, because an AudioClip nothing references natively is unloaded with the next scene's assets - observed as `alert clip ready` logging a second time (the clip being rebuilt mid-session) after the boot plays. What to look for on a launch: `[Alert] watching the notify hub for the game-update notification`, then `[Alert] alert clip ready from ...` the first time the alert is about to play, then either `[Alert] playing the new-update alert (the startup test (Alert.TestOnStartup))` if that switch is on, or - in a normal install - `[Alert] the server pushed the game-update notification (Id "27")` followed by a play line naming that id. A launch that plays nothing at all is the expected case. No server change was needed for any of this: the deployed server already sends `Id "27"` with an empty payload, so the alert works as soon as the new client DLL is installed - no rebuild, no redeploy. The comment at that branch in `AdminPanelAPI` now records that the frame is a cue rather than an announcement, and that it has to stay id-only. ## 2026-10-01 22:00 - the last three `Malformed Response` lines, and the envelope a message rides in The 21:37 `BepInEx/LogOutput.log` is the first run against a server carrying the club-route, filter and carousel work, and it is down to **three** parse failures from the dozen-per-boot of the earlier runs. `LogGate` prints each distinct one once, so three lines is three routes: | Body the client printed | Route | Why | |---|---|---| | `'[ { "latestMessage": … } ]'` | `GET /chat/thread?maxCount=50&mode=0` | the message's `contents` | | `'{}'` | `GET /econ/api/subscriptionseasons/v1/seasons/current` | an empty object is not a season | | `'[]'` | `GET /api/progressionEvents/active` | an array is not a `long?` | The routes are identifiable from the printed body and the request log around it: those two `{}` and `[]` routes are the only ones in that window that answer those bodies (`subscriptionseasons` was the branch's one remaining `return Ok(new { })`, and `progressionEvents/active` answered `Array.Empty