My project was running successfully on cloud run and I recently added https://www.npmjs.com/package/express-static-gzip package to serve my pre gzipped assets and what I noticed is after deploying to cloud run the pre gzipped assets are not recognized by the browser (it's working perfectly on localhost)
Also I noticed an error in stackdriver logs.
Container Sandbox Limitation: Unsupported syscall
statx(0xffffff9c,0x3e2292ff7208,0x0,0xfff,0x3e2292ff6df0,0x3e2292ff6f10).
Please, refer to https://gvisor.dev/c/linux/amd64/statx for more
information.
Also noticed the assets served from google cloud run don't have accept-encoding header (When looking into the source code of express-static-gzip package, it uses nodejs file read calls, I assume that file read calls may causing error in gVisor)
Update:
Getting this "Container Sandbox Limitation: Unsupported syscall" error even after removing express-static-gzip package too.
Does anyone know about this error?
AFAIK the "statx" system call is implemented in gVisor (since June 19). Maybe Cloud Run isn't using the latest release yet.
This is worth noting while running on Google Cloud Run when you see unsupported syscall error in logs:
Most of the time, failed syscalls don’t mean your app is failing. Node.js, here, is trying to use statx if it’s available, and falling back to stat system call, which is supported.
Most languages will explicitly print a stack trace while crashing or they will throw an exception when the system call fails. I don’t see that happening here.
Related
I have been hunting down the answer to this particular answer for 2 days with no luck.
I updated the Firebase CLI per their request, and then it was incompatible with my NodeJS, so I had to update that to NodeJS 16. After I did that, I am not able to deploy my functions anymore to Firebase, and just get this non-descript error:
Cloud Runtime Config is currently experiencing issues,
which is preventing your functions from being deployed.
I have tried everything I can think of..
Used NVM to try different versions of Node like 10, 12, 14
Updated the Engine in the Package JSON to all different versions
Deleted all my functions from GCP and tried to just reinstall from scratch.
None of those things have done anything to even change the error message, so I have no idea what is going on or even able to see any logs.
I did try to deploy to our STAGING environment and get a different error
Error: Failed to load environment variables from .env.:
- Error Key GCLOUD_PROJECT is reserved for internal use.
I am not sure what changed with this update, but has anyone else seen/solved this error?
I'm having the same issue, and seems to be related to the project data in gcloud/firebase runtime config data, because I can deploy the same code, in other project.
After downgrading firebase-tools to 11.1.0, the deploy worked as before.
I have NextJS app with SSG. This functionality was added recently and according to it I should do next-export after next-build to get static files. But after appearing in 9.4 of Incremental Static Regeneration I need to keep server on by npm-start command (in my case I use custom server file with next-express functionality). It works good locally and It works good when I get artifact from Azure. But It doesn't work globally when it will be deployed finally. Help please
Through my attempts, I found that it is impossible to install globally or use next in Azure Web App. That is, it cannot be deployed through Github.Deploying using other methods such as FTP cannot run successfully. It should be related to the azure node environment.
But the method provided in this post says that it can be processed by adding web.config. I think it should be useful and helpful to you. Please read it carefully and try it.
You also can read this document, maybe it useful to you.
Despite re-deploying and even disabling/re-enabling the application Google App Engine keeps trying to run the npm start script from an old version of the app. I noticed this because it used to try to run a migration script, then start the server. Now the migration script errors, which is what got my attention.
I've since tried to also update the version number in the package.json since the logs that are failing specified it was trying to run version 1.0.0 of my app. So I figured maybe I need to bump the version.
Despite that, the log that errors still says PROJECT_NAME#1.0.0 start: npm run migrate && node src/server.js which is clearly the old one.
I started a project on Node.js Flexible environment for Google App Engine, then switched to Standard environment (which was released shortly after I started the project). I'm speculating that perhaps it's trying to run flexible environment script too? But, I don't know how to make it stop.
Oh, one more important detail: The app is running and working despite supposedly erroring on startup. So it definitely seems like it's trying to run both versions and only one is succeeding.
It turns out there was an old instance running in the "flexible" environment.
Deploying a new "default" service running in "standard" environment does not seem to stop other deployed versions in the "flexible" environment.
The fix involved opening Google's Cloud Console for App Engine, clicking "versions" and finding/stopping/deleting the old versions from "flexible" environment.
Huge thanks to #Steren for helping me figure out what was going on.
I'm working with Firebase cloud functions and facing errors while deploying the functions. There are different errors every time. Right now, it's "Server Error: Unexpected Response. Please try again". Whereas, Sometimes it's "Server Error. socket hang up"
I checked firebase-debug.log file, which states that service is not available, whereas, as per Status Dashboard, it's working fine
Another Issue with Naming Convention:
Apart from this, i'm facing issues in deployment when i change the function name from helloWorld to something else. It's quite strange as i've total three functions. Two of them are working fine, whereas, when i change the name of helloWorld to something like generateWeeklyReport, newThreadsReport, weeklyReport it fails every time.
I'm using Spark plan of Firebase and right now the names of functions in my index.js file are: helloWorld, quickChatUserReport, activeThreadsReport. Is there any naming convention, or is there any limitation on the number of functions in this plan? I couldn't find anything in the documentation. Please guide.
Side Note: I read that Kaspersky Endpoint security blocks callbacks resulting in deployment failure. I turned off the protection while deploying function + I'm using node version 9.5.0
The issue in my case was that I updated node version after installing firebase tools. This is the thing which caused the problem and I was not even able to run the functions on my localhost.
I had to uninstall firebase tools completely from my machine, remove the node_modules folder from my project and then reinstall both. It worked.
Commands I used are:
npm uninstall -g firebase-tools
npm install -g firebase-tools
Then I tested my functions as:
firebase deploy --only functions --debug //deployment on cloud
firebase serve --only functions --debug //testing on localhost
Adding the --debug flag to your deploy command can provide some additional details
firebase deploy --debug --only functions
It looks like there have been some intermittent service disruptions with cloud functions over the past week, and I wouldn't be surprised if that is what you are experiencing currently, though the Firebase team isn't reporting any outages currently.
My attempted deploy just now failed with the following error:
[2018-03-08T16:55:56.923Z] Error: Firebase.authWithCustomToken failed: First argument must be a valid credential (a string).
However, when I confirm I'm authenticated via "firebase login" I receive:
Already logged in as xxx#gmail.com
I've had this happen on and off over the past few days and it doesn't seem to be related to anything specific in my code or setup.
UPDATE: My deploys just started working again
I have used weinre in the past for debugging sites remotely because it lets me see the remote console log. Today, I came back to it to debug a remote site after some months of not using it. I'm getting this error in the console with the same setup I always used:
Widgetic SDK: Error: No receiver for d!
It appears to be an error in an inner lib called Widgetic SDK. It must be that they changed something because there is no version number in the sdk.js file.
I checked and I have the latest weinre version in npm (npm install weinre).
Is weinre still supported?
weinre hasn't been updated in quite a while, and there are no current plans to update it in the near future.
See the yellow note on the home page https://people.apache.org/~pmuellr/weinre/docs/latest/ for information regarding native alternatives to using weinre.
I'm not familiar with the "Widgetic SDK", so can't really provide any advice on how to fix that particular issue.
All that Weinre does in this case is display console output. If Weinre itself was at fault here, then there was no output whatsoever. If you see your client in the list of your Weinre server, then Weinre should be working fine.
Whether Weinre is active:
The way it works is you install Weinre and run a Weinre server. So whether it works depends on your Weinre installation, not on whatever happens online - unless you update Weinre that is. But as was pointed out by another user, Weinre is not really being developed anymore.
In my opinion, since you haven't changed anything with your setup and include the widgetic SDK from an online source as is suggested by the error message, in all likelihood there is a conflict between your implementation and the current version of their SDK that is being inbound by you. It does not seem like a Weinre error to me.
In case you are wondering, we are using Weinre to remotely monitor and debug web-applications as I am speaking, so it is definitely not dead yet.