Thanks for the reproduction @tilmannb, I saw MSW in the error message and tried commenting out these lines internally and that made the error message go away, so maybe it’s related to MSW and how it’s set up/torn down. (Nothing actionable yet, just updating.)
1 Like
A fatal runtime error occurred when rendering react-dom.development.js
Element type is invalid: expected a string (for built-in components) or a class/function (for composite
components) but got: undefined. You likely forgot to export your component from
the file it's defined in, or you might have mixed up default and named imports.
Check the render method of `App`.
Hit this error going from 1.3 to 5.2. I spent about 2 hours on it. Figured out it revolves around decoupled auth from v4!
I reinstalled firebase auth following this guide: Redwood v4.0.0 Upgrade Guide which cleared the react-dom error. Now, I am on to a different error.
I am getting “Exception in getAuthenticationContext: Failed to determine project ID: Error while making request: getaddrinfo ENOTFOUND metadata.google.internal.” I will update if I find the fix.
@PantheRedEye that’s quite the upgrade! 
The last error you posted sounds like you didn’t configure the FIREBASE_PROJECT_ID environment variable appropriately maybe?
1 Like
Yeah, it sure was a jump (I have passed beyond this issue and now have hit another issue (below) :smh:) I copied my firebaseConfig object from my 1.2 App.js straight to the new web/src/auth.ts, so I expected everything to work correctly:
const firebaseConfig = {
apiKey: process.env.REACT_APP_FIREBASE_apiKey,
authDomain: process.env.REACT_APP_FIREBASE_authDomain,
databaseURL: process.env.REACT_APP_FIREBASE_databaseURL,
projectId: process.env.REACT_APP_FIREBASE_projectId,
storageBucket: process.env.REACT_APP_FIREBASE_storageBucket,
messagingSenderId: process.env.REACT_APP_FIREBASE_messagingSenderId,
}
However, by reading through your, @Tobbe, and @rapzo’s work around the firebase-admin version, I traced the issue to a variable on the api side in api/lib/auth.ts:
const adminApp = admin.initializeApp({
projectId: process.env.FIREBASE_PROJECT_ID,
})
That defaults to process.env.FIREBASE_PROJECT_ID, so I had to update the env name to match my env name: process.env.REACT_APP_FIREBASE_projectId.
Now the api is crashing when web starts up. API runs fine without web up, but as soon as web side spins up or refreshes, it crashes with PrismaClientUnknownRequestError: Response from the Engine was empty and its referencing @prisma\client\runtime\library.js
After troubleshooting for so long today, I just cloned and went through everything from scratch in-case I had muddied up something unintentionally along the way… and it looks like that did the trick! 
I believe the upgrade has gone through. Will post back if any issues come up. 
edit: I am pretty sure it was a node_modules issue…
@tilmannb I just reverted to v4.5.0 to see what would happen when running the test; were you getting the following message all along?
console.warn
[MSW] Warning: captured a request without a matching request handler:
• GET http://localhost/test
If you still wish to intercept this unhandled request, please create a request handler for it.
Read more: https://mswjs.io/docs/getting-started/mocks
If not, were you doing anything to mock the request on Jest or MSW’s side?
@dom I see you point here. One could argue that a test without mocking the request does not make sense.
And yes: I saw the warning on 4.x but did not care and did not mock the request in any way. It did not break the build pipeline. Seems like with 5.x it breaks the build pipeline and the error message is very hard understand. Might be a problem new redwood users run into.
It is not a blocker for me. We upgraded to 5.2 and everything else works as expected. We just skipped those tests for now.
Ah sorry @tilmannb, I wasn’t trying to make a point but just gather information. Thanks for confirming! I’m not actually sure if the framework lets users mock arbitrary requests with MSW. If not, that sounds like something we should think about supporting given MSW is set up already for GraphQL requests. Glad to hear you were able to upgrade in the meantime though!
Sorry @dom, I should have written: Your answer gave me an aha moment.
But I think we got to the bottom of it.
I just realized we are having one other problem. After building (deployment or yarn rw serve web) we see this error message in the browser console (was not there with 4.x). Any suggestions how to find the culprit?
Error 418
Hydration failed because the initial UI does not match what was rendered on the server.
Error 423
There was an error while hydrating. Because the error happened outside of a Suspense boundary, the entire root will switch to client rendering.
(3 more things:
- We are using vite
- we are prerendering
- it seems there is no impact in functionality)
a little late to this party (@dom thanks for helping out here) - one thing to try is using happy-dom instead of jsdom (so many doms in this thread…). I also ran into TypeError: Cannot read properties of null (reading '_location'). In my case happy-dom resolved my issue. Not sure how/if we want to call this out to new users (my suggestion is to create a separate post in a category such as Solutions and document the ideas/workarounds there).
fwiw, it ultimately did have to do with msw/jest/jsdom and the async teardown of my use of loading json via fetch in a component.
1 Like
Hey @tilmannb, that error only occurs for prerendered pages, so you can narrow down where it may be happening by only looking at those.
Of those, do any render Cells? If so this error may be expected since the content does differ between the server and the client-side render.
Initially we had this somewhat fixed by wrapping Cells in Suspense to tell React that the difference in content is expected. It seems like recently React went from acknowledging this to emitting an error still. If what I said above fits what you’re seeing, we can silence the error in the console using React’s onError callbacks.
1 Like
Hi! I’m facing with this issue when trying to run this codemod npx @redwoodjs/codemods@canary cell-query-result
Hello, no I didn’t
Okay would you be comfortable sharing the arguments to your cell’s Success, Failure etc. with me - you can direct message me if that’s better. I would need to test why the particular way the arguments are being passed is breaking the parsing. Sorry this hasn’t been smooth sailing for you with this particular codemod.
I know it’s less than ideal but it should also be possible to manually scan through your cells to check if they are using any of the props we’ve now hid behind queryResult. It should be fine for all the cells which just use the data returned to them. However, if they use refetch for example then that would need to be extracted out of queryResult like so: queryResult: { refetch }.
One quick check might be to run yarn rw lint and look for errors in your cells. In v5 that should highlight if you’re using any of the properties we’ve moved into queryResult.
I’m happy to help further if I can!
2 Likes
Thanks for these upgrade guides!
I have rarely hit errors that aren’t covered in the upgrade notes, or addressed in subsequent comments.
I also hit the error related to serverless deploys (netlify or vercel) not finding the redwood.toml.
I upgraded recently from 3.5 to 4 and now was doing 4 to 5.0.0.
If anyone else is like me and updating incrementally (and didn’t want to jump to v6 until I made sure v5 worked) it is probably easier to go straight to 5.0.1.
3 Likes