Bug: DS crashes during player join after save accumulates state — gRPC IOCP assertion
Running the DS in Docker on Linux via Wine (wine-staging on debian bookworm, depot 4129621 manifest dated 2026-04-19). Flagging because the assertion looks like something that could also fire on native Windows under the right conditions.
Repro: Played several hours, party all reached level 9, then on the next session the server crashes the instant any player tries to join. Boot itself is fine — crash is during map preload on join. Deterministic on this save; a fresh world and an Apr 21 backup both work.
Crash signature:
R5LogNet: Error: FR5NetModule::StartupModule::<lambda>
ASSERTION FAILED: result.bytes_transferred == buffer_->Length()
[grpcRepoCheckoutDir/src/core/lib/event_engine/windows/windows_endpoint.cc:355]
Predictor in logs: R5LogBLDalAQ::DetectProblems logs "EXTREMELY slow" on the broken save's DB load (8600ms). Healthy saves load in ~1.5s. The threshold between "Slow" and "EXTREMELY slow" warnings in your own code seems to line up with whether the crash fires — might be a useful internal canary.
Save size isn't the issue: 15M Apr 21 save loads clean, 12M Apr 23 save crashes. Something state-specific, not aggregate size.
My guess (take with salt): gRPC's Windows IOCP endpoint asserts the full buffer transferred. Wine's IOCP emulation can deliver partial completions real Windows usually doesn't — but the save-state dependence suggests the DS might also be issuing a read that legitimately comes back short under some condition, and the assertion just hides it under Wine first.
Workaround that worked: restored an older flat-copy backup from SaveProfiles/Default_Backups/ and updated WorldIslandId in ServerDescription.json to point at the restored UUID. Happy to share the broken RocksDB snapshot if a dev wants it for repro — I kept a cold copy.
#DS crash on player join — gRPC windows_endpoint.cc:355 assertion (bytes_transferred != buffer length
burnt owl
burnt owl
Update — progressive failure, not a one-time save corruption
Restored the newest Default_Backups/ snapshot (~36h before the original crash), played on it for ~18 hours of session time across multiple sessions, then it crashed on the next join in exactly the same way. Same assertion, same windows_endpoint.cc:355. So this isn't a particular save getting corrupted — any save will eventually trigger it with enough use.
A couple more things I noticed with a longer log window this time:
Running constantly in the background from session start, on every save tested (both the original and the restored backup):
R5Error Report Calls TotalNum 35. UniqueNum 1
[R5BLDalAsyncQueue.cpp:1192] count 35
That's 7 DAL async-queue errors per minute, firing continuously. Suspect that's what's gradually poisoning the RocksDB state until the next on-join gRPC message is big enough to hit the Wine IOCP partial-read case.
Predictor just before the crash:
R5BLDalAsyncQueue::DetectProblems — Slow task. Task was finished in 2415 ms.
That's "Slow", not "EXTREMELY slow" — so the threshold at which the assertion actually fires is lower than your own EXTREMELY-slow warning level.
Also correcting my earlier "empty server" framing — the trigger is the incoming connection itself, not the server being empty. First incident crashed while another party member was in-game and I joined (kicked them). Second incident was an empty server. Running-idle-with-nobody-joining is fine; it's the on-join path that dies. DB load time on the restored save went from ~1.5s on its first boot to 8s+ by the end — the degradation is visible just in startup timing.
TL;DR: older backups buy more session-hours before the crash, not immunity. The R5BLDalAsyncQueue.cpp:1192 error stream seems like the most investigable piece since it's happening independently of anything Wine-related.
gusty spade
Thanks for the report, our dedicated server does not support linux for now, but we're aiming to provide a proper linux server in the future.
burnt owl
ah, yeha linux support is big for DS because of things like docker
mental yarrow