I ran into this error when trying to build nextjs commerce into an existing monorepo. There were a slew of other errors resulting from switching to yarn workspaces and turbo, but this one was the most cryptic. I was able to determine that the files in the repo were perfectly fine by successfully deploying the same files in a different repo and different project. So the question is WHY IS THIS HAPPENING only for this project deploy on Vercel in my monorepo?
This can be caused if you have next#latest as one of the dependencies in a related project. If you examine the failing build's warnings carefully you will notice:
warning Pattern ["next#latest"] is trying to unpack in the same destination "/vercel/.cache/yarn/v6/npm-next-12.1.5-7a07687579ddce61ee519493e1c178d83abac063-integrity/node_modules/next" as pattern ["next#^12.0.8","next#^12.0.8","next#^12.0.8","next#^12.0.8"]. This could result in non-deterministic behavior, skipping.
This is the revealing error. The manifested problem in my case was that the error above. However I suspect it could show up in other ways. This is just one of the gotchas you should be aware of if using yarn workspaces. Moved to next#latest to ^12.0.8 and suddenly all problems will vanish. You're welcome. Don't waste a day on this like I did.
Related
Background:
We are have noticed that in production and in some staging environments, that the onClick handlers on a SSR page are failing to be called. By comparing working and non-working (npm run start) deployments we've determined that the non-working deployments are not calling the render() methods of the components on the page immediately after page reload, whereas the working deployments do. We are assuming that means that hydration is not occurring.
Development deployments (npm run dev) work flawlessly
We are seeing no browser-side console messages.
We are seeing no server side warnings
The npm build --debug suggests only to upgrade to the new ChunkGraph API. Otherwise no warnings.
We are now wondering...
QQ:
Short of starting with a fresh create-next-app again and gradually evolving the app towards our current implementation until it breaks, what are the suggested ways of determining the root cause(s) of a problem like this?
For some reason, my hydration issues only showed up in production, and only on the server. Running next build and next start didn't show any errors. Since user3624334's answer didn't really help me, I figured I'd reply with how I ended up finding the culprit.
Since I deploy to Vercel, and use Vercel's review apps, I ended up creating a Pull Request where I remove half of the page that was having the hydration issues, and continued bisecting until I found out which component was causing the issues. It took me three tries to find the component.
Once I had the component it was quite easy to figure out what was causing the issues (for me the hydration issue was caused by a timestamp being rendered in different ways).
This also explains why user3624334's answer didn't work for me, since I opened the page straight after building, at which point the time was still the same as during next build!
One challenge here is that it appears that when SSR page hydration fails in next.js, a warning message will not necessarily be generated.
I hope someone has a better suggestion than the following, but I will offer this human script that worked several times for me:
git checkout -b "hydration-problem-02" to create a branch for this effort
add a console.log('render called') to the top of the render() method of pages/_app.js. This should produce a message on each hydrate, making it easy to notice when the page does/does-not hydrate.
Then repeatedly:
simplify a significant portion of the app.
npm run dev to run in dev mode
confirm that your change did not break the app in unexpected ways
rm .next/ node_modules/ package-lock.json
npm install && npm run build && npm run start
confirm that the above command completed successfully
refresh the page in the browser
check for the message in the browser console.
git commit -am "msg that indicates what you changed and if it helped"
if the problem remains, repeat these steps
Doing the commits above should help make the process more fool-proof. Ex. If you think you might have forgotten to test in production mode, you can go back to that commit and retest to confirm you did not mis-test.
Once you have a working and non-working commit of the app, you can do a binary search for the error, either adding or removing smaller and smaller pieces of function.
The root causes of quiet hydration failures I've seen include:
two modules that mutually import each other
an import '..../bootstrap.js' in a component rather than _app.js
Just recently I am starting to experience an issue when trying to deploy my functions through Firebase. When running the command firebase deploy --only functions one of my four functions deploy correctly, but the other three throw this error in the firebase-tools console:
Deployment error.
Build failed: Build error details not available. Please check the logs at url to my GCP logs
When I look at the logs the error message that shows for each function that is failing is:
ERROR: build step 3 "us.gcr.io/fn-img/buildpacks/nodejs10/builder:nodejs10_20200922_20_RC00" failed: step exited with non-zero status: 46
I have searched and googled for quite a while now and I cannot find anyone reporting the same error code, having the same non-zero status returned, or having functions fail on step 3. There doesn't seem to be much for documentation on troubleshooting the errors either.
Hopefully someone here can point me in the right direction.
Thanks!
The error seems to be caused by a missing (or not accessible) file in the history/restore functionality of Firebase. Don't know the reason for this.
A workaround that worked for me was:
Remove the functions in the web console
Deploy normally > firebase deploy
Answering since I can't comment in response to xaphod, Markus's fix worked for me, thank you mate! Deleting the function means it creates a new one rather than trying to restore it, which is the failed step 3 in the build process.
In response to xaphod, I did setup a lifecycle rule for old files in the artifacts bucket, it was by far my biggest bucket in storage and was pushing the free tier limit. I set it up a bit short probably, delete 5 days after last updated time, but surprisingly didn't run into this issue until today (possibly because I usually just deploy them all whenever I update one). I removed the lifecycle rule for now, although I'd rather it not run up the storage space again, I might end up contacting support to see if there's a way to lifecycle them without deleting the most recent, not sure why it doesn't just clear out the old images on updates though.
Found the post that suggested setting up lifecycle rules, firebase storage artifacts is huge, and did some testing as well, deleted all the files in us.artifacts and deployed all my functions (got errors on all them, only deleted the function that I needed to update earlier and deployed it by itself). Doesn't cause any errors, just takes a bit longer, so I think the issue can be fixed by deleting them all or deleting nothing, probably going to set the lifecycle rule to delete immediately and deal with the increased deploy time, rather than the cost of firebase storage.
I'm suddenly not able to publish my dot net core project, having made no known changes, so this seems mysteriously frustrating atm... (compounded by consistent troubles with project build issues for months now, while using dot net core for my back end server).
When I go to publish, it fails and gives me the error message:
"Publishing failed."
Inspecting the logs, I see every single razor view has a warning or error ending with the same message:
"*.cshtml (-1): Targeted tag name cannot be null or whitespace."
And finally, the commandline error:
"C:\Program
Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.0\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(60,5):
Error MSB3073: The command ""dotnet" exec --runtimeconfig"
is spat out, leaving me without even enough of a hint to the problem to even know where to look.
Any ideas what kind of steps I can take to trouble shoot this sort of thing?
If I don't solve this soon I think it's the final straw with dot net core for me... I wanted to to like it... I really did... I've spent more time trying to make it simply build, (following everything by the book too!) than I've spent coding! The biggest headache was definitely the upgrade to dotnetcore 2.0... even with Microsofts instructions.
As I noted in commets I had the same issue as you. I didn't do any significat changes in codebase but suddenly encountered that msdeploy package is failing to built. At the same time rebuilding project in vs and via cli works fine.
It may sound very silly but I just removed obj and bin folders in my project and after then dotnet publish started working fine as before.
I had <Private>false</Private> under one of my References. Simply removing it fixed my issue. I got the idea from here: https://stackoverflow.com/a/46066976/1777780
If deleting bin and obj and restoring then publishing/running do not work for you, try removing anything that appears to be unneeded from your proj.
After having a 4-month break from my .NET project I suddenly run into this error:
Could not find a part of the path c:\Users\...myusername...\.nuget\packages\.tools\Microsoft.Extensions.SecretManager.Tools
Can anybody explain why I should suddenly get this kind of error? I have checked that Microsoft.Extensions.SecretManager.Tools is not found in the path listed here. I will try to install the SecretManager (although I installed it one year ago), but I'm still confused why I get the error now.
Take a look if you have the package folder in your local machine, maybe when you added the new packages to a project the TFS marked them as pending to check-in and then later you removed them manually from your hard drive, at that moment the tfs has a package pending to upload that is not physically present on the hard drive and that is the error you are getting
I am having trouble with my Meteor up, which is perfectly functional on localhost and on Modulus. When I try to deploy to a *.meteor.com instance the upload fails and I get a very cryptic error. The first line is the gist of it I guess
Error: not a tracked temp dir: /Users/valentin/.meteor/packages/velocity_core/.0.4.5.1dbi101++os.osx.x86_64+web.browser+web.cordova
I have tried installing and reinstalling velocity and tried deploying it with/without, the error persists. There are a bunch of hidden files in the folder the error points too. Deleting the one mention in the error simply creates new ones and throws an error again (naming a different folder though) Does anyone have an idea what it is about?
I had the same problem with another meteor package. It was solved after I delete everything from myapp/.meteor/local/ directory.
I think you can leave your local db there (myapp/.meteor/local/db), but I did not check if it still be working. (I've deleted all and probably it is the same as running meteor reset for your local project.)
OK, this seems to work: You have to manually downgrade the meteor version to 1.0.2.1, by editing .meteor/release and changing the version number. (There's a fix in dev, so it should be solved in a more complete fashion soon.)
Were you trying to deploy while your meteor app still ran in localhost? I faced the same problem for another package but resolved it by stopping my local meteor app first then deploy.