@jonoc330 we’ve identified at least one of the performance concerns and released a patch. Could you try with the v6.0.6 patch when you have the chance? We’ll keep working on this in the meantime, thanks!
Hey there,
Going through the upgrade process now and logging out now longer works properly. It keeps recursively calling one of my routes and gets stuck in an infinite loop. This has never happened before the upgrade.
Did anything change with how the Set and Private components handle the unauthenticated props by chance? That’s the only thing I can think of that would be causing this. I think I could probably get around it for now by navigating directly to the login page after calling logOut, but seems like something weird is going on so wanted to mention. Otherwise the guide has been great, thanks!
We had a similar issue and it was a race condition. Logout seems to be longer in v6 and, after call logout without await and then navigate to a public route, user was still logged in, redirecting to a private route. It caused an infinite loop. Now our logout function is async and use await when calling Redwood logout.
1 Like
In case someone else runs into this, we just upgraded to Redwood V6.1.0 today with some initial issues. Initially, Vite was not loading. On a Windows machine, it was failing silently and on a Mac it was throwing errors as if the Vite was not setup (but it was). Eventually tracked it down to an inability for yarn to run the mjs files. Due to an issue, we had over a year ago, we had reverted to Yarn V1. but that other item was no longer a problem, so this prompted a Yarn version upgrade, which addressed the Vite Issue we were experiencing.
So, RW Vite configuration does not appear to be compatible with Yarn V1 (which hopefully no one else is still using)!
Overall, we can use Vite now, but there are some other items to address, so for the moment, we continue to use Webpack, but we plan to coming back to Vite in the future to test some more. At least we are on Redwood V6.1.0 now. Thanks to everyone who put effort into this!
Hi,
is my assumption correct, that cannot be nested anymore?
I have a case where route would not be rendered anymore after navigating back and forth between route and route2.
My workaround is to move CompA in CompB and CompC. But this leads to flickering layout. Every page navigation the page is blank first.
<Set wrap={CompA}>
<Set wrap={CompB}>
<Route ... name="route">
</Set>
<Set wrap={CompC}>
<Route ... name="route2">
</Set>
</Set>
<Set wrap={CompB}>
<Route ... name="route">
</Set>
<Set wrap={CompC}>
<Route ... name="route2">
</Set>
const CompB=(props)=> <CompA>
{prop.children}
</CompA>
const CompC....
When we run our frontend tests after the upgrade to using vite (yarn rw test web), we noticed an issue with an environment variable that we don’t define (RWJS_DEBUG_ENV). Has anyone run into this or know how to work around it? It seems to be pulling it from @redwoodjs/web/dist/components/DevFatalErrorPage
an environment variable that we don’t define (RWJS_DEBUG_ENV).
Hey @link-boris - thanks for reporting this, I do think its a legit issue, but somewhere in your test your layout is also erroring out I think!
This can totally be valid though, maybe you’re testing what happens when the layout errors, but any chance you could share your test so I can reproduce?
In the meantime I’ll get the fix ready, but some more info would really help me validate that my fix works.
Hey all, I think I messed up something during the upgrade and having a lazy brain moment. I am getting the following error since I migrated to the latest version. Any ideas 
It seems like a Set fully remounted on navigation.
Just try
<Set wrap={CompA}>
<Route ... name="route">
<Route ... name="route2">
</Set>
const CompA = ()=>{
useEffect(()=>{ console.log("mount") , [] })
return <></>
}
This leads to unwanted issues like flickering or in my case refs for portals are suddenly null after navigation.
Should I open an issue?
Hey @dennemark, yeah open an issue because this is something we tested for and definitely don’t want to regress on. Thanks!
EDIT: FIXED, potentially something weird with Vercel since fixed.
Upgraded to v6.1 and seem to be having a problem between Vercel/Graphql API in deployment.
Works in local, and I have v6.0.5 on other project where I can access /api/graphql but the v6.1 is getting this pop-up which is new to me on anything involving backend:
The “learn how to fix the error” just goes back to serverless function docs.
It is erroring on dbAuth and vercel logs have:
Invoke Error {"errorType":"TypeError","errorMessage":"mod[funcName] is not a function","stack":["TypeError: mod[funcName] is not a function"," at Runtime.internal [as handler] (/var/task/___vc/__launcher.js:47:25)"," at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1147:29)"]}
A little bit of a weird one I am trying to wrap my head around.
It still builds, front end things run, and localhost works as intended.
Hey @QuinnsCode, we saw this in our deploy CI as well. After debugging for a bit, we looped in the Vercel team and they said it was an internal issue. Earlier today they said it was resolved, and our deploy CI has gone back up. Have you tried redeploying recently?
1 Like
It is back up! I have the best timing messing with things.
I wasn’t sure if it was what I was messing with on Prisma Proxy/Accelerate, but seemed to be on Vercel’s side despite that authoritative splash that is honestly 95% right where I probably blew something up haha.
1 Like
In regards to the Subscriptions error:
api | You must specify one of @requireAuth, @skipAuth or a custom directive for
api | - id Subscription
api | - name Subscription
api | - description Subscription
api | - price Subscription
api | - currency Subscription
api | - features Subscription
api |
api | [GQL Server Error] - Schema validation failed
Changing it to fetchSubscriptions works, but the error persists when I close my server and run yarn rw dev. What’s interesting is while re-running the server and seeing the error, if I change the naming for the subscriptions service/sdl, the error is gone but I’m back to the error loop when I close and re-run the server.
Has anyone run into this error loop?
I also verified this during a failed preview build via Vercel
Hi, the issue with using Subscription as a type when it is a reserved name was addressed in fix: Improve GraphQL Schema Validation to allow Subscription types when not using Realtime and ensure schema does not use reserved names by dthyresson · Pull Request #9005 · redwoodjs/redwood · GitHub and in 6.0.4.
Could you try updating to the latest version of Redwood and trying again?
Thanks
Updating from 6.1.1 to 6.2.0 fails on the first build step for us, doesn’t even lint.
❯ yarn rw lint
Oops! Something went wrong! :(
ESLint: 8.46.0
ESLint couldn't find the plugin "@babel/eslint-plugin".
Build step:
Building API...
✖ Building API... [FAILED: Cannot find module '@babel/plugin-transform-runtime'
Require stack:
- /project/node_modules/@redwoodjs/babel-config/node_modules/@babel/core/lib/config/files/plugins.js
- /project/node_modules/@redwoodjs/babel-config/node_modules/@babel/core/lib/config/files/index.js
- /project/node_modules/@redwoodjs/babel-config/node_modules/@babel/core/lib/index.js
- /project/node_modules/@redwoodjs/babel-config/dist/api.js
- /project/node_modules/@redwoodjs/babel-config/dist/index.js
- /project/node_modules/@redwoodjs/internal/dist/build/api.js
- /project/node_modules/@redwoodjs/cli/dist/commands/buildHandler.js
Make sure that all the Babel plugins and presets you are using
are defined as dependencies or devDependencies in your package.json
file. It's possible that the missing plugin is loaded by a preset
you are using that forgot to add the plugin to its dependencies: you
can workaround this problem by explicitly adding the missing package
to your top-level package.json.
]
We are seeing a new error after upgrading when running yarn rw dev that the web side compiles much faster - so fast that it actually tries to connect to the API side before that side is done compiling, leading to a “Forbidden” error page every time we start our server which is a bit annoying. Anyone else experiencing this or have a suggested workaround?
@dthyresson Thank you for the reply! I am currently using version 6.2.0 as this error occurred while trying to upgrade to v6.0.0. I referenced the previous Subscription error others were facing and it was initially resolved by changing the name, but that did not resolve it as I outlined in my initial post.
Hey @razzeee, I just released a patch for this, could you see if upgrading to v6.2.1 fixes it for you? Thanks!