Summary
Since October 24, an existing UEFN project no longer completes the normal session connection reliably. Upload/cooking and client content preparation can finish, but LoadingNewContent ends in an approximately 30-second Valkyrie beacon timeout. Fortnite can sometimes enter the island or reconnect while UEFN remains disconnected, preventing the normal memory-calculation workflow. Authorized testers joining an affected private version through an island code have also reported Application Hang Detected. Another small UEFN project launches successfully on the same PC. UEFN and Fortnite builds both verified: 42.40 CL 59343437. Root cause is unknown.
Please select what you are reporting on:
Unreal Editor for Fortnite
What Type of Bug are you experiencing?
Stability
Steps to Reproduce
- Open the affected existing project in UEFN 42.40.
- Launch a session using the normal workflow.
- Wait through preparation, validation, upload/cooking and client content loading.
- Observe LoadingNewContent failing to complete normally and a Valkyrie beacon disconnect after approximately 30 seconds.
- On attempts that reconnect or allow manually starting the game, a subsequent in-game transition can stall Fortnite for 40–46 seconds, sometimes recovering and sometimes reporting Application Hang Detected.
- Authorized testers have also encountered the hang on an affected private island version without a live UEFN session. A small test project loads on the same PC.
Expected Result
Fortnite loads the island without a prolonged game-thread stall; UEFN reaches and maintains a fully connected Ready session, memory calculation is available, and authorized testers can join the private version without an application hang.
Observed Result
Repeated approximately 30-second Valkyrie beacon timeouts even in attempts where client/server content preparation has already reported ready. Fortnite sometimes reconnects, but can stall 40–46 seconds during base entry/streaming. Client stall scopes repeatedly include STAT_FAsyncPackage_FlushAsyncLoadingGameThread and STAT_UEngine_BlockTillLevelStreamingCompleted. Some attempts recover; others end in Application Hang Detected. A local full MapCheck returned 0 errors and 0 warnings, although separate CDN x509 and internal Fortnite dependency warnings are also logged. No root cause or durable fix has been confirmed.
Platform(s)
Windows PC; UEFN and Fortnite 42.40 CL 59343437. Testers also report a Fortnite client application hang on the affected private island version.
Additional Notes
Timeline and scope
The project worked previously. Available logs show a completed loading attempt on October 24 at 18:51 UTC and a failing attempt at 19:27 UTC. Verse/data changes occurred in between, but causation has NOT been established. No clean targeted revert of those changes has been completed.
Tests already performed
Experimental content tests were performed on a backed-up diagnostic copy and then reverted.
- Restarted Windows, Fortnite and UEFN; terminated remaining game processes: issue persisted.
- Verified matching installed and running Fortnite/UEFN builds.
- Regenerated ValkyrieUploadTemp: timeout reproduced.
- Later moved aside UEFN Intermediate, generated Verse caches and the writable Engine DerivedDataCache with both applications closed and backups verified. The editor reopened, but a fresh session result after this broader cleanup has not yet been confirmed.
- Full local MapCheck: 0 errors and 0 warnings. Separate internal Fortnite dependency and CDN certificate warnings remain; relevance unknown.
- Reduced runtime streaming loading range on the copy: timeout persisted; client stall approximately 43.9 seconds. Original settings restored.
- Delayed Verse OnBegin entry points by 120 seconds: timeout persisted. This does not rule out device/default-data loading before OnBegin. Original sources restored.
- Tried -NoTimeouts: approximately 30-second disconnect persisted. Normal launch restored.
- Excluded individual runtime Verse devices and complementary device groups: no single cause isolated; timeouts persisted.
- Control with all Verse device actors marked editor-only: LoadingNewContent completed and Ready was reached. Gameplay devices were absent, so this is NOT a usable fix.
- Reintroducing a single device family reproduced the timeout. This suggests a device/data-loading interaction, but does not prove a loop, a specific device bug or a size limit.
- Device asset files restored byte-for-byte after the tests.
- Temporarily removed decorative visual effects: no improvement; effects restored.
- Epic Launcher installation verification has not yet been completed.
Timing evidence from diagnostic attempts (UTC, October 25)
Failed attempt: server content ready at 16:03:11.157; client content ready at 16:03:11.824; timeout at 16:03:42.354.
Control without runtime Verse devices: server ready at 16:28:18.609; client ready at 16:28:19.409; LoadingNewContent completed at 16:28:32.364; Ready at 16:28:32.365.
Client stall markers
Repeated scopes: STAT_FAsyncPackage_FlushAsyncLoadingGameThread and STAT_UEngine_BlockTillLevelStreamingCompleted.
Some fatal stalls were preceded by “TryCollectGarbage forcing GC after 11 skipped attempts”. This correlation does NOT prove garbage collection is the root cause.
Additional certificate warnings
“LogIas: Warning: LatencyTest Error … x509 verification error (20)” repeats for Epic CDN latency probes on CloudFront, Akamai and Fastly. Similar warnings appear during resource validation under FortValidator_FortExposedActors. Their relation to the timeout is unknown.
Questions for Epic
- Which supported logs/traces can distinguish an async-loading/streaming stall from a backend content-beacon issue?
- Is there a known 42.40 device/default-data loading issue that can hold LoadingNewContent beyond the beacon timeout before OnBegin runs?
- Can generated Verse data or serialized references trigger this without a compile or local MapCheck error?
- Are IAS x509 error (20) warnings known to prevent session readiness, or do they only affect latency probing?
- What supported diagnostic procedure should we follow while preserving the existing project?
Project identifiers, island codes, personal information, IP addresses, source code and raw logs are intentionally omitted from this public report. Relevant diagnostics can be supplied privately through an official Epic support channel if requested.