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
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 a Wordle-esque app that I want to deploy using Azure. Repo here. It is a fork from a popular open-source project, and I can also locally build and run the game. Locally, it runs perfectly.
I am trying to use Azure App Services to deploy it, using a Github Action. All the Actions pass, and the App can be successfully built. However, when I try to view the deployment here the only error I am receiving is
You do not have permission to view this directory or page.
Since it runs locally, and it pass its github action build, I do not know how to proceed here. I have tried restarting the app, and changing the resources I am using to host it, but that does not work. Some other answers seem to suggest the problem is about it not finding index.html, but I can access that through https://shetland-wordle.azurewebsites.net/public/index.html and the page is blank.
If i look under wwwroot/ in the Azure debugger I see the following file structure:
Any help would be appreciated
turns out it was something strange with package.json. I needed to change the path to my react scripts:
"start": "node_modules/react-scripts/bin/react-scripts.js start"
Not sure if its good practise to do this, but it works now
I recently (2 days ago) upgraded the node runtime engine on our Cloud Functions instance from Node 10 to 12. (Not sure that is a factor, but it is a recent change.)
Since the upgrade I have been using the Cloud Functions project without trouble. Today is the first time I have done a deploy SINCE the deployment to change the node engine. After I did the deploy, ALL of the Runtime Environment Variables were deleted except one labeled FIREBASE_CONFIG.
As a test, I added another test environment variable via the Cloud Functions console UI. I refreshed the page to ensure the variable was there. Then, I ran another deploy, using this command:
firebase use {project_name} && firebase deploy --only functions:{function_name}
After the deploy completed, I refreshed the environment variables page and found that the test variable I had created was now missing.
I'm quite stumped. Any ideas? Thank you!
It is true that the Firebase CLI manages enviroment configuration and does not allow us to set the ENV variables of the runtime during deployment. This has been explained on other post as well, like this one.
I guess you are aware of the difference between the Cloud Functions Runtime Variables and the Firebase Environment configuration, so I will just leave it here as a friendly reminder.
Regarding the actual issue (New deployments erasing previously set "Cloud Functions Runtime Variables"), I believe this must have been something they fixed already, because I have tested with version 9.10.2 of the firebase CLI, and I could not replicate the issue on my end.
I recommend checking the CLI version that you have (firebase --version) and, if you still experience the same issue, provide us with the steps you took.
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.
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.