Closed tmcw closed 2 years ago
@tmcw unfortunately @beerose and I are unable to reproduce the issue in a new blitz app. Maybe there is a cache issue from your blitz upgrade? Try deleting node_modules
, .blitz
, and .next
.
If that doesn't work, can you provide a full repo that we can clone and test? We'd love to get this fixed for you.
Sorry, working on it. This bug is unbelievably hard to diagnose. What I have so far is that if I manually set __BLITZ_SUSPENSE_ENABLED=true
in my environment, I can get pages to successfully render.
But if I don't, the behavior of SSR simply always does what it shouldn't: it crashes, every time, even after wiping node_modules, .blitz, and .next. I thought it might be that I was using Suspense
in my layout, but that wasn't it.
Okay! I've finally distilled a repro!
https://github.com/tmcw/bug-distill
If you run
yarn
yarn build
yarn start
And request the first page, you should get the error.
Thanks for the repo! I can confirm that something weird happens and that the behaviour was different with Blitz 0.38. We'll investigate and get back to you as soon as possible
@flybayer I think the issue (or part of it) is somewhere here: https://github.com/blitz-js/blitz/blob/canary/nextjs/packages/next/data-client/react-query.tsx#L79, as process.env.__BLITZ_SUSPENSE_ENABLED
is undefined in that place. That's also why running it with __BLITZ_SUSPENSE_ENABLED=true
solves the issue. That also makes sense timing-wise as those files were moved/edited 3 months ago. So we also have to set it somewhere for blitz start
?
@beerose hmm, so BLITZ_SUSPENSE_ENABLED isn't working at all for blitz start
or only for blitz start
runtime? Ah yeah so maybe it's working at build time where it gets string replaced by webpack, but for gSSP at runtime, it uses env from Node. So yes, probably are not setting BLITZ_SUSPENSE_ENABLED at runtime properly.
So in order to fix it, I first tried to create a minimal repro from a new Blitz app. I used @tmcw's code, but it was working fine, so I compared deps, and turns out it fails only with some experimental react versions (I tried a few). New Blitz apps have 18 alpha so that works, and that's why we weren't able to reproduce it before.
With experimental version and blitz start
runtime __BLITZ_SUSPENSE_ENABLED
is false in all the places, but I'm not sure what is causing it.
The fix currently is to update React version to an alpha one (or another working version).
I'm going to close this issue, as it doesn't seem to be Blitz specific, but rather something was wrong with a few React versions. Please reopen if this happens again.
Got it - thanks for digging in to this!
What is the problem?
Routes that use
getServerProps
are rendered with SSR. If they useuseQuery
, the value of the query result, if you have aresolver.authorize
call, isundefined
. As a result, any page that relies on auseQuery
value that is non-nullable and runs on the server will cause that route to crash in production.Any of the following would be better:
useQuery
's result is nullable even if the query it's referring to is non-nullable, then its return type should be nullable. Right now, TypeScript allows you to rely on non-nullable query results that become nullable.useQuery
produced the correct result by actually running the authenticated query.useQuery
did not run.Paste all your error logs here:
Paste all relevant code snippets here:
Example query resolver:
Example from a slightly-modified new Blitz app that uses a query:
What are detailed steps to reproduce this?
getServerSideProps
and an authenticated, non-nullqueryRun
blitz -v
and paste the output here:Please include below any other applicable logs and screenshots that show your problem:
No response