Summary
In Epic Games Launcher’s Fab Library tab, clicking “Update” on any Vault/Fab content asset downloads the new version successfully (BuildPatchServices reports ErrorCode: OK, FailureType: NoError), but the local Fab library database is never updated to reflect it. On the next Launcher restart, the same items show “Update available” again, even though the new version’s files are already fully present on disk.
What type of bug are you experiencing?
Other
Steps to Reproduce
Open the Fab Library tab, click “Update” on any asset with an update available.
Wait for the download to finish.
Fully quit Epic Games Launcher (tray icon “Exit”, not just closing the window).
Relaunch and reopen the Fab Library tab.
Observed: Same items show “Update available” again, as if nothing was downloaded.
Expected: Items should show as up to date.
Expected Result
After clicking “Update” on a Fab Library asset and letting the download finish, the asset should be marked as up to date — both immediately in the UI and after fully quitting and relaunching Epic Games Launcher.
Observed Result
The download completes with no errors, but after fully quitting and relaunching Epic Games Launcher, the same asset shows “Update available” again, as if it had never been updated. This repeats every time and affects multiple different Fab Library assets. The local library index file (VaultCache\FabLibrary\listings_v1.db) never changes, even though the download itself succeeds and the corresponding cache folder gets updated on disk.
Platform
pc
Operating System
win10 64
Additional Notes
Diagnostic Evidence
listings_v1.db’s modification timestamp never changes across multiple successful update cycles, even though the corresponding VaultCache<AssetHash>V\ folders get fresh timestamps each time.
Launcher log shows ErrorCode: OK / NumFailedDownloads: 0 for every affected update — the download layer completes without error.
Every Launcher session logs LogWebBrowser: Warning: Timed out waiting for startup ack from EpicWebHelper PID — the embedded CEF helper process rendering the Fab UI fails its startup handshake every time, regardless of cache state.
Suspicion: the “mark as updated” callback is driven from the Fab web UI inside EpicWebHelper back to the native process, and never fires because the handshake never completes.
Already Ruled Out
File/folder permissions (full control confirmed)
Corrupted browser cache (fully cleared, timeout still occurs immediately in fresh session)
Corrupted/blocked EpicWebHelper.exe binary (intact, correct size)
Firewall blocking the helper process (no rule found)
Stale manifest paths (separate subsystem, unrelated — we independently fixed manifest-path issues for other apps without affecting this bug)
Suggested Area to Investigate
The IPC/callback path between EpicWebHelper and the native process responsible for writing VaultCache\FabLibrary\listings_v1.db after a successful download. The EpicWebHelper startup ack timeout is reproducible on every session in our environment and looks like the proximate cause.