In my Firebase project I have a functions.pubsub.schedule().onRun() that runs every 5 minutes to perform some calendar related tasks. It needs to look up in my Firestore collections and does so with a .get() query.
This has been working fine until sometime 2020-03-13 in the morning where the function started to throw
2020-03-13 09:36:02.326 CET scheduledHooks 1042277797598294
Error: INTERNAL ERROR: Client is not yet ready to issue requests.
at Firestore.get projectId [as projectId] (/srv/functions/node_modules/#google-cloud/firestore/build/src/index.js:401:19)
at Query.toProto (/srv/functions/node_modules/#google-cloud/firestore/build/src/reference.js:1556:42) at Query._get (/srv/functions/node_modules/#google-cloud/firestore/build/src/reference.js:1466:30)
at Query.get (/srv/functions/node_modules/#google-cloud/firestore/build/src/reference.js:1457:21)
at FirebaseActivitiesCollection.<anonymous> (/srv/functions/lib/collections/activities/FirebaseActivitiesCollection.js:32:40)
at Generator.next (<anonymous>) at /srv/functions/lib/collections/activities/FirebaseActivitiesCollection.js:8:71
at new Promise (<anonymous>) at __awaiter (/srv/functions/lib/collections/activities/FirebaseActivitiesCollection.js:4:12)
at FirebaseActivitiesCollection.getActivitiesByInterval (/srv/functions/lib/collections/activities/FirebaseActivitiesCollection.js:27:16)
I can't track that I have changed anything, could it be that Firebase made some changes that I should be aware of or am I missing an obvious clue in this error message?
My other Cloud Functions and the Firebase JavaScript SDK still work fine.
Extra info: The same code works on my other environment where I have not deployed. This of course led me to search for changes in the deployed code, but I can't find any!?
It seems by the error, that the project was not connected and initialized correctly. As per the official API here, this error occurs when:
Returns the Project ID for this Firestore instance. Validates that
initializeIfNeeded() was called before.
I would recommend you to check that. In case you are still facing, I would say for you to contact the Firebase Free Support. Since you mentioned that it was working until yesterday morning, it might be some change on their side.
Hope this helps!
This turned out to be a very simple matter of initialization of Firebase:
Before I had:
// Initialize firebase
admin.initializeApp(functions.config().firebase)
..And it worked fine until it didn't anymore.
Now I have:
// Initialize firebase
admin.initializeApp()
... And it works again
Got the same error while running some jest tests involving firebase. Problem was that I didn't have GOOGLE_APPLICATION_CREDENTIALS environment variable set.
Since I was running them locally on my machine, exporting this variable in terminal before running the tests was sufficient for my case:
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/credentials/file.json
Related
I added Firebase Functions secrets via the CLI as described in the docs. The secrets are populated correctly in process.env both in deployed and emulated functions UNLESS the --inspect-functions flag is set. In that case, the secrets in process.env are undefined and no errors are displayed.
The issue only occurs when I run: firebase emulators:start --inspect-functions. Other notes:
I have the correct permissions set for the service account and there are no permissions errors.
I'm using .runWith correctly, since the same code works in the other environments. Here's how it's structured:
exports.functionName = functions
.runWith({secrets: ['SECRET_KEY', "SECRET_KEY_TEST"]})
.https.onCall(async (data, context) => {
// Code here.
});
There are no errors when the emulators start, which you'd expect if the configuration had a problem.
There is no mention of this being a limitation in the functions docs. The emulator docs mention the --inspect-functions flag causes a subtle behavior difference, but it doesn't seem relevant:
Note that when this flag is supplied, the Cloud Functions emulator
switches to a special serialized execution mode in which functions are
executed in a single process, in sequential (FIFO) order; this
simplifies function debugging, though the behavior differs from
multi-process, parallel execution of functions in the cloud.
I'm running firebase-tools version 10.7.0 on Windows 10. Thanks for any assistance figuring this one out!
I'm following the guide at https://firebase.google.com/docs/functions/unit-testing, but I always get " FirebaseError: Missing or insufficient permissions" when I run my test. I have the correct service-account.json file and I'm setting up firebase-functions-test with it (that part goes without error).
I've tried it with the emulator running (setting the FIRESTORE_EMULATOR_HOST var), and without it (which I assume uses live data) but I always get this error, as soon as my code under test does a db request such as:
data = await db().collection('/machines').get()
So my function under test is getting called, but it just can't do anything.
I also tried calling firebase.initializeApp() the same way I do in my front-end app, but that doesn't help, although without it I get the error telling me to call Firebase App.initializeApp().
firebase use is set to my current project.
I also tried running my test as firebase emulators:exec jest, no difference.
Any ideas?
I have a Firebase Function that subscribes to a Cloud PubSub topic. App is initialized very simply like this:
import * as admin from 'firebase-admin';
admin.initializeApp();
I'm getting this error:
"Error: Could not load the default credentials. Browse to https://cloud.google.com/docs/authentication/getting-started for more information.
at GoogleAuth.getApplicationDefaultAsync (/srv/functions/node_modules/google-auth-library/build/src/auth/googleauth.js:161:19)
at process._tickCallback (internal/process/next_tick.js:68:7)"
Here's the weird thing. It typically works. In other words, if I trigger it a second time it works. And a third time. Most often it seems to fail the first time it runs after a new firebase deploy and possibly on a "cold start."
Not sure what I'm doing wrong and why it would fail only on the first run.
SOLVED! This answer helped:
Error: Could not load the default credentials (Firebase function to firestore)
From within a Firebase Function for an API call, I was publishing to a Cloud PubSub topic like this:
pubsub.topic(topicName).publish(dataBuffer, customAttributes)
I was not awaiting the response and was immediately sending the 2XX HTTP response back to the client. The execution seemed to continue fine, but obviously it did not behave as intended.
Sometimes the API response call itself would fail (and never publish the message), but sometimes not. In other cases, the publish would succeed but the Firebase Function subscribing to the topic would fail!
In all cases, this seemed to resolve itself after running the script a second time. For this reason, I still believe it had something to do with a cold start.
But since I changed it to await like this:
await pubsub.topic(topicName).publish(dataBuffer, customAttributes)
I have not seen this problem happen again.
I am getting this error every so many runs with my HTTP Firebase Cloud Function:
Function execution took ****ms, finished with status: 'connection error'
It happens inconsistently but I can't quite narrow down what the problem is. I don't believe the error is in my app as it's not showing an error printout. And my own connection with firebase while running this cloud function isn't cutting out.
Any ideas why Firebase randomly fails cloud function executions with "connection error"?
Function execution took ****ms, finished with status: 'connection error' or ECONNRESET usually happens when a function doesn’t know whether a promise resolved or not.
Every promise must be returned, as mentioned in the docs here. There is also a blog post (with helpful video!) about this.
A couple of examples of unreturned promises:
exports.someFunc = functions.database.ref('/some/path').onCreate(event => {
let db = admin.database();
// UNRETURNED PROMISE
db.ref('/some/path').remove();
return db.ref('/some/other/path').set(event.data.val());
});
exports.makeUppercase = functions.database.ref('/hello/{pushId}').onWrite(event => {
return event.data.ref.set('world').then(snap => {
// UNRETURNED PROMISE
admin.database().ref('lastwrite').set(admin.database.ServerValue.TIMESTAMP);
});
});
exports.makeUppercase = functions.database.ref('/hello/{pushId}').onWrite(event => {
// UNRETURNED PROMISE
event.data.ref.set('world').then(snap => {
return admin.database().ref('lastwrite').set(admin.database.ServerValue.TIMESTAMP);
});
});
To help catch this mistake before deploying code, check out this eslint rule.
For an in-depth look at promises, here are some helpful resources:
Mozilla docs
Ponyfoo promises deep dive
Links to the ECMA standard
Egghead.io course
Even though this question has an approved answer, you may have followed the steps in that answer and still reached a point where the error was still occurring.
In that case, we were informed by GCP that there's a known issue with Node 8 CFs and this connection error, for which the workaround is to update the node version to 10.
Related github issue: https://github.com/firebase/firebase-functions/issues/429
Specific comment: https://github.com/firebase/firebase-functions/issues/429#issuecomment-577324193
I think it might be too many simultaneous firebase database connections :/ https://groups.google.com/forum/#!topic/firebase-talk/4RjyYIDqMVQ
I faced the same issue while deploying uninstallTracking event to firebase for android device,
Turns out that the property I was trying to access was available for only some users ,
So when it couldn't find the property for those other users it gives this error
So first just check the property you are trying to access is there or not
I've been getting this on an HTTP trigger that immediately calls response.end() with no other code!
I had a very complex function that was working great then it stopped working due to this error. I tried for hours playing with my code until there was nothing left but a response.end() and still the error persisted.
I found that by deleting the trigger (deploying my triggers with the offending trigger commented out), then deploying again with the trigger uncommented seems to have fixed it.
Perhaps there is a bug that works in that gets reset when you delete the trigger in the cloud.
Hope this saves somebody some frustration.
it could be outdated libraries.
go to terminal
inside functions folder write command
npm outdated
this will show all libraries to require to be updated.
To update libraries write command
npm update
deploy cloud functions with
firebase deploy --only functions
For debugging purposes, I did the following:
response.send(someArray.length)
...which resulted in the following:
response.send(218)
...which resulted in a bodyless response, just a "status code" (namely 218) being sent. To fix this, I did:
response.send("count: " + someArray.length)
I'm using Google Cloud Functions to:
Watch for a new Firebase entry
Download a file that's referenced in the Firebase entry
Generate a thumbnail based on that file.
Upload the thumbnail to the cloud bucket.
Unfortunately I'm getting ECONNRESET errors repeatedly on step 4, and the only way to fix it seems to be to redeploy the function. Any ideas how to further debug this?
Edit:
It seems like many times when this happens, when I try to deploy the function again, it errors, and I have to run the deploy twice. Is something hanging or something?
Update May 9 2017
According to this thread, the google cloud nodejs API developers have made some changes to the defaults that are used when initializing that should solve these ECONNRESET socket issues.
From #stephen++ on github GoogleCloudPlatform/google-cloud-node issue 2254:
We have disabled the forever agent by default in Cloud Function
environments. If you un- and re-install #google-cloud/storage, you
will pick up the new behavior automatically. Thanks for all of the
helpful debugging, everyone!
Older Post Follows:
The solution for me to similar ECONNRESET issues using storage on the cloud functions platform was to use npm:promise-retry, but set up your own retry strategy because the default of 10 retries is too many.
I reported an ECONNRESET issue with cloud functions to Google Support (which you might star if you are also getting ECONNRESET in this context but not in other contexts) and they replied with a "won't fix" that the behavior is expected. Google support said the socket that the API client library uses to connect times out after a few minutes, and then when your cloud function tries to use it again you get ECONNRESET. They recommended adding autoRetry:true when initializing the storage API, but that did not help.
The ECONNRESETs happen on the read side too. In both read and write cases promise-retry helps, and most of the time with only 1 retry needed to reset the bad socket.
So I wrote npm:pipe-to-storage to return a promise to do the retries, check md5, etc., but I haven't tested it with binary data, only text, so I don't know if you could use it with image files. The calls would look like this:
const fs = require('fs');
const storage = require('#google-cloud/storage')();
const pipeToStorage = require('pipe-to-storage')(storage);
const source = ()=>(fs.createReadStream("/path/to/your/file/to/upload"));
pipeToStorage(source, bucketName, fileNameInBucket).then(//do next step);
See also How do I read the contents of a new cloud storage file of type .json from within a cloud function?
You can directly report a bug to the Firebase Support team, or open a support ticket with Firebase to troubleshoot a specific issue.
You may also report a Cloud Functions specific issue in the Google Issue Tracker, which is similar to Stack Overflow in that it is accessible by the public (but specifically used for filing issue reports).