We’ve been getting Sentry reports from our Linux Development servers, on occasion over the last 6 or so months, of crashes as they’ve asserted due to a fatal logging event with “Loading is stuck, flush will never finish”.
The “callstack” of this EPS post has the dumped state from async loading that was logged just before the assertion, from one of the incidents.
- Only reported from Linux Development Servers, which are the only platform and only build configuration of server that we run and would get reports from. No reports from clients, not happening in editor.
- Only ever occurs while the process is still in `FEngineLoop:Init`, not generally once the engine is ticking, so it’s initial async loading. Not during gameplay or general engine looping and ticking.
- Has happened about 30 or so times over 6 months. I’m still discussing internally to gauge what fraction of server spin ups this represents.
- In that time span, we upgraded from UE 5.5.1 to UE 5.7.4. About a month ago.
- Incidents have spiked in the last week or two with no clear cause or correlation. Might be an alternative explanation though, like more playtests or build deployments.
I’ve found a few other EPS threads about this issue posted over the last few years. For brevity, I’ll leave most of them out, but they generally ended with suggestions to integrate changelists that are already present for us or other configuration changes that are moot as they’re default by now like using Zen loader.
[This one written in [Content removed] translated within Google Chrome, is from January 2026, mentions two CLs that are are claimed to be in UE 5.7 and there is mention of a remaining `UE-224115`, but I have not been able to find reference to this in any UE release notes nor in the changelist descriptions of changes to `AsyncLoading2.cpp` in Epic’s Main after the last change that was integrated into 5.7.4.
Looking at changes after 5.7.4, there are numerous changes related to async loading and Zen loader that *could* maybe be relevant but it’s very hard to tell which might be relevant here.
With regards to the dumped async loading state, “Zen package None state WaitingForIo” looks suspicious to me at a glance. First off, the “package None”. But looking at the code, it appears that the data structures tracking these things will have a `UPackageName` set to `None` until the package summary is read. It also says it’s “WaitingForIo”, but for this fatal log to go off, `PendingIoRequestsCounter.load()` has to have returned 0. So perhaps there’s IO that’s not yet pending but needs to be initiated, but hasn’t yet? But the default timeout is 2 minutes. It seems likely that something has indeed permanently broken and will not resolve, if the necessary IO to read the package summary hasn’t been queued up in 2 whole minutes of complete inactivity. I don’t totally understand the meaning of “BarrierCount” versus having an Empty or NonEmpty event queue.
I haven’t exhaustively proven that every incident involved a “Zen package None state WaitingForIo”, but all of the handful I have looked through manually have involved that. Am I on a wild goose chase? Is this a red herring? I checked several of these logs and the dependent package that ends up waiting for this “None” is not consistent and there was no common package dependency among those different dependent packages.
[Attachment Removed]