Bundlers like webpack split an application into chunks loaded on demand, each file named with a content hash. ChunkLoadError: Loading chunk 5 failed means the browser asked for one of those files and did not get it. The classic timing is minutes after a new deployment: a visitor's browser still holds the previous version's HTML, which references chunk files by their old hashes, and the new deployment replaced them. The visitor did nothing wrong and neither, exactly, did the code; the two versions disagree about file names.
publicPath or CDN path in the build, so chunk URLs point somewhere the files were never uploaded; this variant fails for every visitor, including fresh ones, which distinguishes it from the deployment race.window.addEventListener('error') handler that detects ChunkLoadError and reloads the page once (guarded by a session flag so a real outage does not become a reload loop). This converts a stranded visitor into a refreshed one.Why does it start right after a release and then stop? The pool of stale pages drains: visitors refresh, close tabs, or their cached HTML expires. The error rate after a deploy is a measure of how long old HTML and old chunks were allowed to coexist, or not.
Does code splitting cause this? Code splitting creates the chunks; the error comes from version skew between the page and the files, or plain network failure. Apps without splitting cannot hit it, but they pay with one large initial download instead.
A reload fixes it for users, is that acceptable? As a safety net yes, as the only strategy no. Keeping prior assets and uncached HTML removes most occurrences; the reload handler is for the remainder.