Blitz: Multiple simultaneous connections break the app in dev mode

[praneetrohida]

What is the problem?

Opening any blitz app in dev mode on 8 or more devices at the same time in Sizzy breaks the app.

Steps to Reproduce

1. Start any blitz app in dev mode
2. Open the app in Sizzy with 8 or devices in view (a device is equivalent to a tab in Chrome)
3. The app crashes on all the devices, with very high CPU usage, and everything becomes frozen. I sometimes get this error in one of the devices
   

Versions

debug: blitzPkgPath: /Users/praneet/webdev/blitz-demo/node_modules/blitz/dist/index.js
debug: cliPkgPath: /Users/praneet/webdev/blitz-demo/node_modules/@blitzjs/cli/lib/src/index.js 

macOS Catalina | darwin-x64 | Node: v12.18.1

blitz: 0.24.1 (local)

  Package manager: yarn 
  System:
    OS: macOS 10.15.6
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 3.89 GB / 16.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.18.1 - /var/folders/yl/r_sqlm4j4dzdbfp22bhfnws40000gn/T/yarn--1603096129635-0.22168078660086454/node
    Yarn: 1.22.4 - /var/folders/yl/r_sqlm4j4dzdbfp22bhfnws40000gn/T/yarn--1603096129635-0.22168078660086454/yarn
    npm: 6.14.5 - /usr/local/bin/npm
    Watchman: Not Found
  npmPackages:
    @prisma/cli: 2.8.1 => 2.8.1 
    @prisma/client: 2.8.1 => 2.8.1 
    blitz: 0.24.1 => 0.24.1 
    react: 0.0.0-experimental-7f28234f8 => 0.0.0-experimental-7f28234f8 
    react-dom: 0.0.0-experimental-7f28234f8 => 0.0.0-experimental-7f28234f8 
    typescript: 4.0.3 => 4.0.3 

Other

• I individually tested this issue with Next.js, Prisma (with both sqlite and postgres) to check if one of them is causing the issue. However, I found that it happens only when using blitz.
• It happens only when simultaneously loading the app on all the instances. If I start with 6 instances and add 2 more instances incrementally after the first 6 have loaded, then everything works fine unless I reload all the instances

[flybayer]

That doesn't sound good! Thanks for reporting this.

[abuuzayr]

I was able to recreate this sometimes, not with Sizzy - no issues opening 10 devices - but with several open tabs in Chrome (along with the 10 Sizzy devices still open). I don't believe it has to do with browser/HTTL connection limits which was fixed by Sizzy via a workaround but I may be wrong. Even after I got the same Unhandled Runtime Error, I could still open a few tabs after that with no issue.

In the tab with the Error, i found that the Invalid Unicode escape sequence was due to the code in _buildManifest.js being incomplete:

self.__BUILD_MANIFEST = {__rewrites:[],"/":["static\u002Fchunks\u002Fpages\u002Findex.js"],"/404":["static\u002Fchunks\u002Fpages\u002F404.js"],"/_error":["static\u002Fchunks\u002Fpages\u002F_error.js"],sortedPages:["\u002F","\u002F404","\u002F_app","\u002

I would love to work on this if it is something that can be fixed.

[flybayer]

Oh! So the only error you had was the unicode error? That unicode error is a Next bug and isn't related to multiple connections (I get it every so often with a single connection)

[kitze]

@flybayer Sizzy works fine with Next.js, it's something in Blitz that's tripping it up but we cannot figure out what.

[abuuzayr]

@flybayer yes that was the only error I got, and exactly with the steps that you mentioned in the issue. Also @kitze is probably right, I tried the same steps with a plain Next.js project and couldn't get the unicode error. Also, loading/re-loading Sizzy/multiple tabs is much faster too, than with blitz.

With my limited understanding, I think there are much more things running under the hood with blitz than with a plain Next.js project, so it should make sense that there would be more resource usage, but I think we would prefer not to have super high resource usage.

In the Next.js unicode issue's steps to reproduce, Step 4 is to:

Immediately click the localhost:3000 link as soon as it appears

Could this be due to an incomplete build? Then with multiple open tabs leading to high resource usage, the build process becomes slower and increases the occurrence of the unicode error.

[flybayer]

As far as I can tell, the unicode error can simply be ignored for now until the bug is fixed in next. I don't know why this error mainly shows up in blitz.

As for the resource usage & crash, I don't have any ideas right off on what this could be.

Resource usage wise, the only thing blitz adds is a, file watcher and compiler process that copies your source code into .blitz/ and makes a few transforms for queries/mutations. Once that's complete, the next dev server is started similar to yarn next dev .blitz/caches/dev.

Beyond that, blitz doesn't add any hidden things to the actual runtime code in the browser. Only resource usage should come from any direct blitz apis you use like useQuery, useMutation, etc.

One thing you could try is run blitz start, wait for it to boot, then stop it and manually run yarn next dev .blitz/caches/dev. And see if that does anything different.

[flybayer]

After writing that, I got a hunch on what could be the problem.

In the code behind useSession(), we have a PublicDataStore class that sets up a listener on the window storage event to ensure session changes are synchronized between tabs.

And I can see now that we are writing to localstorage on initialization of that class. So perhaps it gets into some type of deadlock or infinite loop if many pages are opened simultaneously.

So if you want to look into this further, I would definitely start there!

[flybayer]

Also, loading/re-loading Sizzy/multiple tabs is much faster too, than with blitz.

Loading/re-loading tabs should have zero difference between next/blitz 🤔

[flybayer]

Fixed by https://github.com/blitz-js/blitz/pull/1453

Available in 0.25.0!

[kitze]

Awesome!! Thanks @flybayer