Hello!
The embedded Sandbox iframe fails to render for any browser with a cold cache. It boots, then a lazy route chunk 404s, the React ErrorBoundary catches it, and you’re left with a blank panel.
This reproduces on your own documentation: open GraphOS Studio Explorer - Apollo GraphQL Docs in a fresh browser profile (or incognito). Where the embedded Sandbox should appear, you get nothing, and the console shows:
Uncaught (in promise) ChunkLoadError: Loading chunk 205 failed.
(error: https://studio-ui-deployments.apollographql.com/build/static/js/205.0d5a1a2496939aa54290.js)
Uncaught (in promise) ChunkLoadError: Loading chunk 4555 failed.
Caused by: React ErrorBoundary ChunkLoadError
at Lazy
at .../build/static/js/app.7d61949a52f859b894cd.js
I hit this first on a self-hosted @apollo/server 5.4.0 gateway (default landing page → ApolloServerPluginLandingPageLocalDefault, embed sandbox v2), and it’s byte-for-byte the same failure: same runtime, same app build, same two chunks.
Diagnosis
https://sandbox.embed.apollographql.com/ currently serves:
build/static/js/runtime.844d53f5587d53fe1118.jsbuild/static/js/app.7d61949a52f859b894cd.js→ 200
Its LaunchDarkly context reports buildTime: 1778077194955 → 2026-05-06T14:19:54Z, a ~3-month-old build. The lazy chunks that build asks for are no longer on the CDN:
| URL | Status |
|---|---|
…/build/static/js/205.0d5a1a2496939aa54290.js |
404 |
…/build/static/js/4555.ba5007906043d02f9d29.js |
404 |
…/build/static/js/app.7d61949a52f859b894cd.js |
200 |
By contrast https://studio.apollographql.com/sandbox/explorer serves app.ee080c1771afb5e11262.js, buildTime: 1785912371990 → 2026-08-05T06:46:11Z, and loads clean.
So the embed host is pinned to (or cached at) an old studio-ui deployment whose split chunks have since been pruned, while top-level Studio is on a current build.
Why this may have gone unreported for a while
Browsers that have used Sandbox for some time still work: Chrome partitions the HTTP cache by top-level site, so a warm partition keeps serving the old, self-consistent bundle. It only breaks on a new site, an incognito window, or a cleared profile — which makes it look like a local/self-hosting problem. That’s exactly how it presented to us (our own dev machines fine, deployed environments broken).
Ruled out
- Not a CSP or hosting issue at our end — the failing fetches happen inside your iframe on your origin, and reproduce on your docs site.
- Not env- or origin-specific — same failure from
http://localhostwith a cold profile. - Not an egress/network block —
app.js,runtime.jsand the CSS all fetch fine from the same host; only the lazy chunks 404, andcurlconfirms the 404s independently of any browser.
Ask: could the embed entry point be repointed at a current studio-ui deployment (or the pruned chunks restored)? And is there a supported way to pin the embed to a known-good version, so a CDN prune can’t take the IDE down again? As far as I can tell the version option on the landing-page plugin only selects the embeddable-sandbox.cdn loader script, not the studio build the iframe loads.
Thanks!