Forge apps can hang on Jira's loading skeleton forever after a transient ERR_SOCKET_NOT_CONNECTED (ECO-1823)

Forge
,
1

If your users report “the app won’t load, just the pulsing grey bars, and clearing my cache fixes it once” — this may not be your app. Jira requests the Forge iframe document exactly once and never retries, so one recoverable socket error from the browser bricks the app until a full page reload. Atlassian has confirmed it: ECO-1823

Customers describe it as: indefinite loading skeleton, no error; clearing the cache fixes it for exactly one load; often one user in an org while everyone else is fine; app updates and reinstalls change nothing.

To confirm, get a HAR and look for a single zero-status entry on .cdn.prod.atlassian-dev.net with _resourceType: document, empty serverIPAddress, no _connectionId, and dns/connect/ssl = -1. That last part is the tell — Chromium took a dead socket from its idle pool, so it never did DNS or a handshake. Everything else on the page will look healthy, and the iframe URL is never requested again.

The three dead ends (we tried all of them)

This is the part that cost us the week:

  • Clearing the cache “works” — but only as a timing side effect. Cache-cold asset requests happen to leave a live connection to the CDN origin open when the iframe is created. Nothing to do with cached data.
  • Flushing socket pools doesn’t help — speculative preconnect refills the pool before the iframe is requested.
  • Incognito/InPrivate doesn’t help — socket pools aren’t cache or profile state. This one is genuinely misleading: it sent us chasing corporate proxies and browser extensions for days, and there were none.

Workaround for affected users

Turn off browser page preloading — that’s what opens the connection that goes stale.

  • Edge: Settings → System and performance → “Preload pages for faster browsing and searching” → off, restart.

Permanent fix for our user, but it’s blunt: it degrades general browsing and is often locked by corporate device policy.

If you’ve seen this

Watch/vote on ECO-1823 and add data points there — especially browser and version, whether preload-off resolved it, and whether you’ve hit it on Connect as well as Forge. We’ve only confirmed Forge custom UI on Edge 153, but nothing in the mechanism looks app- or vendor-specific, so the real blast radius is likely much wider.

2

The HAR signature you describe is the useful part here. We have a small local script that sorts HAR failures into network, Atlassian or app vendor and strips tokens before anything is shared, and right now a zero-status document entry lands in the network bucket, which is exactly the wrong place to send someone for this. Adding your four conditions together (zero status on .cdn.prod.atlassian-dev.net, empty serverIPAddress, no _connectionId, dns/connect/ssl all -1) makes it a separate case with its own label, so it stops reading as a proxy problem. Have you seen it on Chrome as well, or only Edge 153? If you have one of the affected HAR files, I can check whether those four conditions are enough to separate it from ordinary failed requests, or whether something else has to be in the test.