Wp-calypso: [BLOCKER] wp-desktop: Runtime Error: Unable to connect to WordPress.com

Created on 2 Jun 2020 · 13Comments · Source: Automattic/wp-calypso

Description

A runtime error has been introduced to the desktop app, which manifests with the error message in the UI: Unable to connect to WordPress.com

unable-to-connect

Devtools console shows the error:

Uncaught (in promise) Error: Loading chunk 193 failed.
(error: http://127.0.0.1:41050/calypso/fallback/193.js)
    at Function.__webpack_require__.e (entry-main.js:2)
    at entry-main.js:2
    at tryCatch (126.js:2)
    at Generator._invoke (126.js:2)
    at Generator.forEach.prototype.(anonymous function) [as next] (http://127.0.0.1:41050/calypso/fallback/126.js:2:626963)
    at asyncGeneratorStep (126.js:2)
    at _next (126.js:2)

For some reason I was getting inconsistent results when trying to reproduce locally (probably some cached state), so I threw up a test branch which I ran against several Calypso commits.

Test branch CI runs

The error seems to have been introduced with Automattic/wp-calypso@d46489e, which was part of PR #42785 (I can't quite see how the code change would result in the error, though).

Tested the commit immediately before (Automattic/wp-calypso@6891b77) and it completed successfully, which seems to indicate that this code change might be driving the error.

FWIW, it seems the desktop e2e tests in original PR #42785 didn't complete (Mac/e2e test job was marked "canceled"). I have noticed several of these and could be a bug in the canary bridge code that triggers desktop CI.

PR #42785 Desktop CI

Desktop App [Pri] BLOCKER

Source

nsakaimbo

Most helpful comment

Identified and reported a webpack issue: https://github.com/webpack/webpack/issues/11005

We'll need to get rid of the lib/user/utils dynamic import: preferably by getting rid of the circular dependency in some other way.

jsnajdr on 5 Jun 2020

❤3

All 13 comments

It appears that the desktop app may have issues with asynchronously loaded chunks, in some cases. #42785 moved a module to be loaded asynchronously, which was previously loaded synchronously.

@jsnajdr: any idea what could be the issue here?

sgomes on 3 Jun 2020

any idea what could be the issue here?

I've been debugging this for a better part of today 🙂 It seems to be some webpack weirdness. The lib-user-utils chunk is generated, but is not a part of the module numeric ID -> module file name map in the webpack runtime.

jsnajdr on 3 Jun 2020

I've been debugging this for a better part of today 🙂 It seems to be some webpack weirdness. The lib-user-utils chunk is generated, but is not a part of the module numeric ID -> module file name map in the webpack runtime.

Thank you, @jsnajdr! 🙏 Let me know if you need a hand at any point!

sgomes on 3 Jun 2020

Let me know if you need a hand at any point!

So far it seems like a subtle webpack bug.

jsnajdr on 3 Jun 2020

What I know about the issue so far:

The trouble is with dynamically loading the lib/user/utils module. The special thing about it is that it's also bundled statically in entry-main, due to static imports at other places, but is dynamic-only in other entrypoints.

Usually, webpack would recognize a situation where a dynamic import imports something that's already statically bundled. In that case, the dynamic import() call is compiled into a simple Promise.resolve().

But in this case, where there are multiple entrypoints, where the module is statically available only in some of them, webpack gets confused.

It's confused in a case where the webpack runtime is instantiated for each entrypoint separately. Either inline in the entrypoint chunk, or as a separate chunk in the entrypoint's chunk group.

Then webpack fails to include information about that module (the flag that it's already "installed", the mapping from chunk ID to file name, ...) in that custom runtime. Executing the dynamic import() then fails.

Only if there is a single runtime common for all entrypoints, the bug disappears.

The desktop build inlines the runtime into the entrypoint chunk, while a "web" build creates a common runtime for all entrypoints. It's mostly for historical reasons, not exactly intentional. Until recently, wp-desktop didn't do any code splitting and bundled everything into one JS file. Also, at the time when the runtimeChunk configuration was initially created, we even didn't have multiple entrypoints.

So far, I've been unable to isolate the issue and create a minimalistic example.

jsnajdr on 4 Jun 2020

Thanks for the deep dive into this, @jsnajdr!

Until recently, wp-desktop didn't do any code splitting and bundled everything into one JS file

After the code splitting feature flag was merged into Calypso, it seems the Desktop is still building things into one giant file. You can confirm this by looking at release/mac/WordPress.com.app/Contents/Resources/app/build/desktop.js on Mac. 🤔

@sgomes Seems we're currently at a standstill to get this resolved, unfortunately. Is it possible to revert the changes in #42785 while we look into this issue further?

nsakaimbo on 4 Jun 2020

@sgomes Seems we're currently at a standstill to get this resolved, unfortunately. Is it possible to revert the changes in #42785 while we look into this issue further?

Unfortunately, it seems that would break things in Jetpack Cloud 😞 See https://github.com/Automattic/wp-calypso/pull/42763#issuecomment-636142367

sgomes on 4 Jun 2020

😞 Is there another course of action we can take? The last known good SHA of Calypso is from May 29th, and there have been some important features merged since then (e.g. #42752), which we won't be able to deploy with the Desktop app.

My biggest concern is the longer this goes unresolved, the higher risk of more breaking changes introduced as time goes on while CI is effectively offline.

Any thoughts, @griffbrad?

nsakaimbo on 4 Jun 2020

it seems the Desktop is still building things into one giant file. You can confirm this by looking at release/mac/WordPress.com.app/Contents/Resources/app/build/desktop.js on Mac. 🤔

build/desktop.js is the server part of Calypso running in Node.js. That's the "main process" in Electron terminology. The part that recently got code splitting, on the other hand, is the browser app running in the "renderer process". You can see all the JS and CSS chunks in app/calypso/public/fallback.

jsnajdr on 4 Jun 2020

🚀1

Identified and reported a webpack issue: https://github.com/webpack/webpack/issues/11005

We'll need to get rid of the lib/user/utils dynamic import: preferably by getting rid of the circular dependency in some other way.

jsnajdr on 5 Jun 2020

❤3

Amazing work tracking down that webpack issue, @jsnajdr! And glad to hear that there's a way we can unblock wp-desktop and Jetpack Cloud while that's sorted out upstream.