I am trying to display a Streamlit/Hydralit component but, as soon as I deploy it on Cloud Run, I encounter this timeout error (never encountered locally):
Your app is having trouble loading the hydralit_components.NavBar.nav_bar component.
(The app is attempting to load the component from **, and hasn't received its "streamlit:componentReady"** message.)
If this is a development build, have you started the dev server?
If this is a release build, have you compiled the frontend?
For more troubleshooting help, please see the Streamlit Component docs or visit our forums.
How can I solve this relevant issue?
Related
This is my 5th project deployed to the Vercel via GitHub (after almost year break). However after importing the project from the GitHub and pushing it to Vercel I am getting 404 page with a link to unhelpful page with explanation why I might see the 404 page (which naturally does not resolve even remotely the issue). I don't understand. My previous 4 projects were deployed this way and they work to this day. Simple push to the GitHub will update the project and publish it live. The projects says it is build, there are no errors. It works on local building it with npm run dev.
The project was added the recommended way as per the Next documentation using npx - command was copy-pasted from the documentation.
I have consulted this with how to publish Next.js project to Vercel and there are simple 4 steps which I did.
Does anyone maybe had similar experience and managed to resolve this kind of issue? Thank you kindly for your time.
While running yarn build I get the following error:
Error: Missing getServerSnapshot, which is required for server-rendered content. Will revert to client rendering.
This didn't happened to me locally but only on the remote deployment, then I realized that remotely they use the latest amlify and next.js versions:
After updating next.js locally I managed to reproduce it locally - but didn't manage to solve.
There's a GitHub issue that tracks this error: https://github.com/aws-amplify/amplify-ui/issues/1780. A fix for it has been implemented and will be part of the next package release.
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
I have a multi-page web application written in Flutter which uploaded on Firebase hosting . All the pages work fine but half of the homepage is grey. Photo attached. Really appreciate for help.
Also, I'm getting this error when I run: flutter run -d chrome --release
Oops; flutter has exited unexpectedly: "ProcessException: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event
log or use the command-line sxstrace.exe tool for more detail.
Command: C:\Users\abc\AppData\Local\Google\Chrome\Application\chrome.exe --user-data-dir=C:\Users\abc\AppData\Local\Temp\flutter_tools.2b59d482\flutter_tools_chrome_device.4fad7966 --remote-debugging-port=2576 --disable-background-timer-throttling --disable-extensions --disable-popup-blocking --bwsi --no-first-run --no-default-browser-check
--disable-default-apps --disable-translate http://localhost:11541".
I have also faced same issue while host web app in firebase.
the issue is not in firebase host. the issue is in your code. your code will completely work in debug mode. but not in released mode.
check every warning in logs.
it is mostly happen because of wrong use of expanded or flexible widget
I have a strange issue. I build my Meteor app and run it on android device using -
meteor run android-device --mobile-server=<my_aws_ip>:3000
When the app deploys immediately it connects to the server (and my javascripts etc works). After a few seconds, the page refreshs and none of the javascript callbacks work. Please help me debug this issue.
More information: If I change the client (and not the server), and deploy it, for the first few seconds, the changed client gets shown on the phone. After the first few seconds, the version which is present on the server is shown. So I think Cordova or Meteor is trying to fetch the client code from the server, which is breaking the app. Is there a way to prevent this behavior?
Even more data points -
My aws code does NOT have android and ios platforms installed. Because of this, I think the cordova plugins are not installed, causing a JS break somewhere.
Easiest fix I can think of is remove cordova autoupdate. This is being added by meteor-platform package. If I clone meteor-platform and comment out the cordova autoupdate, the app doesn't load.
Is there another way of removing autoupdate?
This sounds like you have a different version of your app deployed at the mobile-server address.
The local code is run in development mode. Your AWS one is likely in production mode (and may contain a syntax error).
When you run your app it sees the code is different and fetches the new/old (different) version with a hot code reload - hence the page refresh/flash.
To fix this, you need to find the syntax error in your code. It's best to view the ADB logger or run with meteor run --verbose android-device ....
This will provide a bit more information such as an Uncaught exception: cannot read .. of null error type error.
It's hard to say what the error is. The error prevents the rest of your code from executing. In production mode the entire project is one JS file. If there is an error of any kind half way along the file, the rest of the file will not execute.
Also, try loading <my_aws_ip>:3000 in your browser and watch for JS errors in the JS console.
You can also run it locally with --production to simulate a production build environment locally.
Enabling autoupdate but without a page refresh:
Reload._reload = function (options) {
console.log("Next load will load new version");
};