Cloud functions context params return undefined












10















I am using cloud functions to listen on new document created on Firestore.



functions.firestore.document('users/{userId}')
.onCreate((snapshot, context) => {
console.log('params', context.params.userId);
});


The logs show undefined instead of the wildcarded param.



This start happening from 15th dec 2018 at midnight.



Is this a bug related to an update of firestore/cloud functions ?
and how we can bypass this issue?










share|improve this question


















  • 3





    We started experiencing this too last night. Possible workaround is to use the ID in the snapshot object, e.g. const userId = snapshot.id;

    – rmac
    Dec 15 '18 at 12:32











  • There is a Github issue for this now: github.com/firebase/firebase-functions/issues/357

    – rmac
    Dec 15 '18 at 14:23






  • 1





    Seems this issue has been posted in Firebase's status dashboard. : status.firebase.google.com/incident/Functions/18044

    – dev.for.fun
    Dec 15 '18 at 19:56
















10















I am using cloud functions to listen on new document created on Firestore.



functions.firestore.document('users/{userId}')
.onCreate((snapshot, context) => {
console.log('params', context.params.userId);
});


The logs show undefined instead of the wildcarded param.



This start happening from 15th dec 2018 at midnight.



Is this a bug related to an update of firestore/cloud functions ?
and how we can bypass this issue?










share|improve this question


















  • 3





    We started experiencing this too last night. Possible workaround is to use the ID in the snapshot object, e.g. const userId = snapshot.id;

    – rmac
    Dec 15 '18 at 12:32











  • There is a Github issue for this now: github.com/firebase/firebase-functions/issues/357

    – rmac
    Dec 15 '18 at 14:23






  • 1





    Seems this issue has been posted in Firebase's status dashboard. : status.firebase.google.com/incident/Functions/18044

    – dev.for.fun
    Dec 15 '18 at 19:56














10












10








10


5






I am using cloud functions to listen on new document created on Firestore.



functions.firestore.document('users/{userId}')
.onCreate((snapshot, context) => {
console.log('params', context.params.userId);
});


The logs show undefined instead of the wildcarded param.



This start happening from 15th dec 2018 at midnight.



Is this a bug related to an update of firestore/cloud functions ?
and how we can bypass this issue?










share|improve this question














I am using cloud functions to listen on new document created on Firestore.



functions.firestore.document('users/{userId}')
.onCreate((snapshot, context) => {
console.log('params', context.params.userId);
});


The logs show undefined instead of the wildcarded param.



This start happening from 15th dec 2018 at midnight.



Is this a bug related to an update of firestore/cloud functions ?
and how we can bypass this issue?







google-cloud-firestore google-cloud-functions






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Dec 15 '18 at 11:59









iouhammiiouhammi

745925




745925








  • 3





    We started experiencing this too last night. Possible workaround is to use the ID in the snapshot object, e.g. const userId = snapshot.id;

    – rmac
    Dec 15 '18 at 12:32











  • There is a Github issue for this now: github.com/firebase/firebase-functions/issues/357

    – rmac
    Dec 15 '18 at 14:23






  • 1





    Seems this issue has been posted in Firebase's status dashboard. : status.firebase.google.com/incident/Functions/18044

    – dev.for.fun
    Dec 15 '18 at 19:56














  • 3





    We started experiencing this too last night. Possible workaround is to use the ID in the snapshot object, e.g. const userId = snapshot.id;

    – rmac
    Dec 15 '18 at 12:32











  • There is a Github issue for this now: github.com/firebase/firebase-functions/issues/357

    – rmac
    Dec 15 '18 at 14:23






  • 1





    Seems this issue has been posted in Firebase's status dashboard. : status.firebase.google.com/incident/Functions/18044

    – dev.for.fun
    Dec 15 '18 at 19:56








3




3





We started experiencing this too last night. Possible workaround is to use the ID in the snapshot object, e.g. const userId = snapshot.id;

– rmac
Dec 15 '18 at 12:32





We started experiencing this too last night. Possible workaround is to use the ID in the snapshot object, e.g. const userId = snapshot.id;

– rmac
Dec 15 '18 at 12:32













There is a Github issue for this now: github.com/firebase/firebase-functions/issues/357

– rmac
Dec 15 '18 at 14:23





There is a Github issue for this now: github.com/firebase/firebase-functions/issues/357

– rmac
Dec 15 '18 at 14:23




1




1





Seems this issue has been posted in Firebase's status dashboard. : status.firebase.google.com/incident/Functions/18044

– dev.for.fun
Dec 15 '18 at 19:56





Seems this issue has been posted in Firebase's status dashboard. : status.firebase.google.com/incident/Functions/18044

– dev.for.fun
Dec 15 '18 at 19:56












2 Answers
2






active

oldest

votes


















9














There seems to be a bug in the Firebase Functions SDK or platform currently (15 December 2018).



Work-around:



Update The proper way to access the parent document ID is through change.after.ref.parent.parent.id or snapshot.ref.parent.parent.id. Note the .parent.parent.



If you are expecting parameters with the document IDs, you can probably work around the problem by using the data provided in the first argument to you function.



Here is an example with an onCreate triggered function:



export const myCreateTriggeredFn = firestore
.document("user/{userId}/friends/{friendId}")
.onCreate((snapshot, context) => {

let { userId, friendId } = context.params;

if (typeof userId !== "string" || typeof friendId !== "string") {
console.warn(`Invalid params, expected 'userId' and 'friendId'`, context.params);

userId = snapshot.ref.parent.parent.id;
friendId = snapshot.id;
}

// Continue your logic here...
});


And for an onWrite triggered function:



export const myChangeTriggeredFn = firestore
.document("user/{userId}/friends/{friendId}")
.onWrite((change, context) => {

let { userId, friendId } = context.params;

if (typeof userId !== "string" || typeof friendId !== "string") {
console.warn(`Invalid params, expected 'userId' and 'friendId'`, context.params);

userId = change.after.ref.parent.parent.id;
friendId = change.after.id;
}

// Continue your logic here...
});


For the sake of completeness and to highlight the bug, both examples shows how you would normally extract the IDs from the context.params and then the added work-around to extract the IDs from the snapshot/change objects.






share|improve this answer





















  • 1





    Thank you. The workaround seems to be working, but I get a new issue not related to my code: TypeError: Cannot read property 'name' of undefined at Firestore.snapshot_ (/user_code/node_modules/firebase-admin/node_modules/@google-cloud/firestore/build/src/index.js:422:127) at beforeSnapshotConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:140:30) at changeConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:144:49) at cloudFunctionNewSignature (/user_code/node_modules/firebase-functions/lib/cloud-functions.

    – iouhammi
    Dec 15 '18 at 13:43








  • 4





    I can't even imagine how many production systems have been broken because of this... Did they make any announcement on it?

    – gatti
    Dec 15 '18 at 14:07











  • @iouhammi we are seeing that error too. Looking into workarounds for that right now.

    – rmac
    Dec 15 '18 at 14:23






  • 1





    @iouhammi I did an update to the examples. snapshot.ref.parent is apparently the collection reference. You must use snapshot.ref.parent.parent to find the parent document.

    – rmac
    Dec 15 '18 at 15:11








  • 2





    Glad I found that. Everything are broken today on our side because of this.

    – Brieuc
    Dec 15 '18 at 15:28



















3














I'm the Google employee working on the incident. There is a known compatibility issue for customers using the SDK when Firestore was in a private alpha and have not upgraded.



Could affected customers who are running their code with an SDK version newer than 0.6.2 respond? If you are running version 0.6.1 you can upgrade to 0.6.2 with no code changes to fix.






share|improve this answer
























  • Which SDK? The "firebase-functions" NPM package? This is an extract from our package.json: ``` "engines": { "node": "8" }, "dependencies": { "@google-cloud/storage": "2.3.1", "firebase-admin": "^6.3.0", "firebase-functions": "^2.1.0" } ```

    – rmac
    Dec 15 '18 at 16:58






  • 1





    the firebase-functions: 2.1.0 is what I was asking about. It seems like firebase-functions may no longer guard against this server change. We are continuing to roll back.

    – Thomas Bouldin
    Dec 15 '18 at 16:59











  • Ok thanks. FYI, I can see in our yarn.lock that we get "@google-cloud/firestore@^0.19.0" indirectly as well.

    – rmac
    Dec 15 '18 at 17:01













  • my dependencies: {"firebase-admin": "^6.0.0", "firebase-functions": "^2.1.0"}. And in the package-lock.json I can see this dependecy "@google-cloud/firestore": "0.16.1", same version required by firebase-admin.

    – iouhammi
    Dec 15 '18 at 17:49






  • 1





    I am using Node 8 as well. My app was down for pretty much the entire day yesterday (IST) and I was glued to my laptop trying to manually do everything that cloud function would do until I had to ask my clients to stop using the app for the last few hours. It's a new app and few clients are using us for their daily billing so it's a big issue if the app just stops working. App is working fine now though. Thanks for the help! Is there any advice on what to do if we face these kind of issues?

    – Nikhil Agarwal
    Dec 16 '18 at 4:14











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53792140%2fcloud-functions-context-params-return-undefined%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









9














There seems to be a bug in the Firebase Functions SDK or platform currently (15 December 2018).



Work-around:



Update The proper way to access the parent document ID is through change.after.ref.parent.parent.id or snapshot.ref.parent.parent.id. Note the .parent.parent.



If you are expecting parameters with the document IDs, you can probably work around the problem by using the data provided in the first argument to you function.



Here is an example with an onCreate triggered function:



export const myCreateTriggeredFn = firestore
.document("user/{userId}/friends/{friendId}")
.onCreate((snapshot, context) => {

let { userId, friendId } = context.params;

if (typeof userId !== "string" || typeof friendId !== "string") {
console.warn(`Invalid params, expected 'userId' and 'friendId'`, context.params);

userId = snapshot.ref.parent.parent.id;
friendId = snapshot.id;
}

// Continue your logic here...
});


And for an onWrite triggered function:



export const myChangeTriggeredFn = firestore
.document("user/{userId}/friends/{friendId}")
.onWrite((change, context) => {

let { userId, friendId } = context.params;

if (typeof userId !== "string" || typeof friendId !== "string") {
console.warn(`Invalid params, expected 'userId' and 'friendId'`, context.params);

userId = change.after.ref.parent.parent.id;
friendId = change.after.id;
}

// Continue your logic here...
});


For the sake of completeness and to highlight the bug, both examples shows how you would normally extract the IDs from the context.params and then the added work-around to extract the IDs from the snapshot/change objects.






share|improve this answer





















  • 1





    Thank you. The workaround seems to be working, but I get a new issue not related to my code: TypeError: Cannot read property 'name' of undefined at Firestore.snapshot_ (/user_code/node_modules/firebase-admin/node_modules/@google-cloud/firestore/build/src/index.js:422:127) at beforeSnapshotConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:140:30) at changeConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:144:49) at cloudFunctionNewSignature (/user_code/node_modules/firebase-functions/lib/cloud-functions.

    – iouhammi
    Dec 15 '18 at 13:43








  • 4





    I can't even imagine how many production systems have been broken because of this... Did they make any announcement on it?

    – gatti
    Dec 15 '18 at 14:07











  • @iouhammi we are seeing that error too. Looking into workarounds for that right now.

    – rmac
    Dec 15 '18 at 14:23






  • 1





    @iouhammi I did an update to the examples. snapshot.ref.parent is apparently the collection reference. You must use snapshot.ref.parent.parent to find the parent document.

    – rmac
    Dec 15 '18 at 15:11








  • 2





    Glad I found that. Everything are broken today on our side because of this.

    – Brieuc
    Dec 15 '18 at 15:28
















9














There seems to be a bug in the Firebase Functions SDK or platform currently (15 December 2018).



Work-around:



Update The proper way to access the parent document ID is through change.after.ref.parent.parent.id or snapshot.ref.parent.parent.id. Note the .parent.parent.



If you are expecting parameters with the document IDs, you can probably work around the problem by using the data provided in the first argument to you function.



Here is an example with an onCreate triggered function:



export const myCreateTriggeredFn = firestore
.document("user/{userId}/friends/{friendId}")
.onCreate((snapshot, context) => {

let { userId, friendId } = context.params;

if (typeof userId !== "string" || typeof friendId !== "string") {
console.warn(`Invalid params, expected 'userId' and 'friendId'`, context.params);

userId = snapshot.ref.parent.parent.id;
friendId = snapshot.id;
}

// Continue your logic here...
});


And for an onWrite triggered function:



export const myChangeTriggeredFn = firestore
.document("user/{userId}/friends/{friendId}")
.onWrite((change, context) => {

let { userId, friendId } = context.params;

if (typeof userId !== "string" || typeof friendId !== "string") {
console.warn(`Invalid params, expected 'userId' and 'friendId'`, context.params);

userId = change.after.ref.parent.parent.id;
friendId = change.after.id;
}

// Continue your logic here...
});


For the sake of completeness and to highlight the bug, both examples shows how you would normally extract the IDs from the context.params and then the added work-around to extract the IDs from the snapshot/change objects.






share|improve this answer





















  • 1





    Thank you. The workaround seems to be working, but I get a new issue not related to my code: TypeError: Cannot read property 'name' of undefined at Firestore.snapshot_ (/user_code/node_modules/firebase-admin/node_modules/@google-cloud/firestore/build/src/index.js:422:127) at beforeSnapshotConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:140:30) at changeConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:144:49) at cloudFunctionNewSignature (/user_code/node_modules/firebase-functions/lib/cloud-functions.

    – iouhammi
    Dec 15 '18 at 13:43








  • 4





    I can't even imagine how many production systems have been broken because of this... Did they make any announcement on it?

    – gatti
    Dec 15 '18 at 14:07











  • @iouhammi we are seeing that error too. Looking into workarounds for that right now.

    – rmac
    Dec 15 '18 at 14:23






  • 1





    @iouhammi I did an update to the examples. snapshot.ref.parent is apparently the collection reference. You must use snapshot.ref.parent.parent to find the parent document.

    – rmac
    Dec 15 '18 at 15:11








  • 2





    Glad I found that. Everything are broken today on our side because of this.

    – Brieuc
    Dec 15 '18 at 15:28














9












9








9







There seems to be a bug in the Firebase Functions SDK or platform currently (15 December 2018).



Work-around:



Update The proper way to access the parent document ID is through change.after.ref.parent.parent.id or snapshot.ref.parent.parent.id. Note the .parent.parent.



If you are expecting parameters with the document IDs, you can probably work around the problem by using the data provided in the first argument to you function.



Here is an example with an onCreate triggered function:



export const myCreateTriggeredFn = firestore
.document("user/{userId}/friends/{friendId}")
.onCreate((snapshot, context) => {

let { userId, friendId } = context.params;

if (typeof userId !== "string" || typeof friendId !== "string") {
console.warn(`Invalid params, expected 'userId' and 'friendId'`, context.params);

userId = snapshot.ref.parent.parent.id;
friendId = snapshot.id;
}

// Continue your logic here...
});


And for an onWrite triggered function:



export const myChangeTriggeredFn = firestore
.document("user/{userId}/friends/{friendId}")
.onWrite((change, context) => {

let { userId, friendId } = context.params;

if (typeof userId !== "string" || typeof friendId !== "string") {
console.warn(`Invalid params, expected 'userId' and 'friendId'`, context.params);

userId = change.after.ref.parent.parent.id;
friendId = change.after.id;
}

// Continue your logic here...
});


For the sake of completeness and to highlight the bug, both examples shows how you would normally extract the IDs from the context.params and then the added work-around to extract the IDs from the snapshot/change objects.






share|improve this answer















There seems to be a bug in the Firebase Functions SDK or platform currently (15 December 2018).



Work-around:



Update The proper way to access the parent document ID is through change.after.ref.parent.parent.id or snapshot.ref.parent.parent.id. Note the .parent.parent.



If you are expecting parameters with the document IDs, you can probably work around the problem by using the data provided in the first argument to you function.



Here is an example with an onCreate triggered function:



export const myCreateTriggeredFn = firestore
.document("user/{userId}/friends/{friendId}")
.onCreate((snapshot, context) => {

let { userId, friendId } = context.params;

if (typeof userId !== "string" || typeof friendId !== "string") {
console.warn(`Invalid params, expected 'userId' and 'friendId'`, context.params);

userId = snapshot.ref.parent.parent.id;
friendId = snapshot.id;
}

// Continue your logic here...
});


And for an onWrite triggered function:



export const myChangeTriggeredFn = firestore
.document("user/{userId}/friends/{friendId}")
.onWrite((change, context) => {

let { userId, friendId } = context.params;

if (typeof userId !== "string" || typeof friendId !== "string") {
console.warn(`Invalid params, expected 'userId' and 'friendId'`, context.params);

userId = change.after.ref.parent.parent.id;
friendId = change.after.id;
}

// Continue your logic here...
});


For the sake of completeness and to highlight the bug, both examples shows how you would normally extract the IDs from the context.params and then the added work-around to extract the IDs from the snapshot/change objects.







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 15 '18 at 16:13

























answered Dec 15 '18 at 12:59









rmacrmac

730512




730512








  • 1





    Thank you. The workaround seems to be working, but I get a new issue not related to my code: TypeError: Cannot read property 'name' of undefined at Firestore.snapshot_ (/user_code/node_modules/firebase-admin/node_modules/@google-cloud/firestore/build/src/index.js:422:127) at beforeSnapshotConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:140:30) at changeConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:144:49) at cloudFunctionNewSignature (/user_code/node_modules/firebase-functions/lib/cloud-functions.

    – iouhammi
    Dec 15 '18 at 13:43








  • 4





    I can't even imagine how many production systems have been broken because of this... Did they make any announcement on it?

    – gatti
    Dec 15 '18 at 14:07











  • @iouhammi we are seeing that error too. Looking into workarounds for that right now.

    – rmac
    Dec 15 '18 at 14:23






  • 1





    @iouhammi I did an update to the examples. snapshot.ref.parent is apparently the collection reference. You must use snapshot.ref.parent.parent to find the parent document.

    – rmac
    Dec 15 '18 at 15:11








  • 2





    Glad I found that. Everything are broken today on our side because of this.

    – Brieuc
    Dec 15 '18 at 15:28














  • 1





    Thank you. The workaround seems to be working, but I get a new issue not related to my code: TypeError: Cannot read property 'name' of undefined at Firestore.snapshot_ (/user_code/node_modules/firebase-admin/node_modules/@google-cloud/firestore/build/src/index.js:422:127) at beforeSnapshotConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:140:30) at changeConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:144:49) at cloudFunctionNewSignature (/user_code/node_modules/firebase-functions/lib/cloud-functions.

    – iouhammi
    Dec 15 '18 at 13:43








  • 4





    I can't even imagine how many production systems have been broken because of this... Did they make any announcement on it?

    – gatti
    Dec 15 '18 at 14:07











  • @iouhammi we are seeing that error too. Looking into workarounds for that right now.

    – rmac
    Dec 15 '18 at 14:23






  • 1





    @iouhammi I did an update to the examples. snapshot.ref.parent is apparently the collection reference. You must use snapshot.ref.parent.parent to find the parent document.

    – rmac
    Dec 15 '18 at 15:11








  • 2





    Glad I found that. Everything are broken today on our side because of this.

    – Brieuc
    Dec 15 '18 at 15:28








1




1





Thank you. The workaround seems to be working, but I get a new issue not related to my code: TypeError: Cannot read property 'name' of undefined at Firestore.snapshot_ (/user_code/node_modules/firebase-admin/node_modules/@google-cloud/firestore/build/src/index.js:422:127) at beforeSnapshotConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:140:30) at changeConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:144:49) at cloudFunctionNewSignature (/user_code/node_modules/firebase-functions/lib/cloud-functions.

– iouhammi
Dec 15 '18 at 13:43







Thank you. The workaround seems to be working, but I get a new issue not related to my code: TypeError: Cannot read property 'name' of undefined at Firestore.snapshot_ (/user_code/node_modules/firebase-admin/node_modules/@google-cloud/firestore/build/src/index.js:422:127) at beforeSnapshotConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:140:30) at changeConstructor (/user_code/node_modules/firebase-functions/lib/providers/firestore.js:144:49) at cloudFunctionNewSignature (/user_code/node_modules/firebase-functions/lib/cloud-functions.

– iouhammi
Dec 15 '18 at 13:43






4




4





I can't even imagine how many production systems have been broken because of this... Did they make any announcement on it?

– gatti
Dec 15 '18 at 14:07





I can't even imagine how many production systems have been broken because of this... Did they make any announcement on it?

– gatti
Dec 15 '18 at 14:07













@iouhammi we are seeing that error too. Looking into workarounds for that right now.

– rmac
Dec 15 '18 at 14:23





@iouhammi we are seeing that error too. Looking into workarounds for that right now.

– rmac
Dec 15 '18 at 14:23




1




1





@iouhammi I did an update to the examples. snapshot.ref.parent is apparently the collection reference. You must use snapshot.ref.parent.parent to find the parent document.

– rmac
Dec 15 '18 at 15:11







@iouhammi I did an update to the examples. snapshot.ref.parent is apparently the collection reference. You must use snapshot.ref.parent.parent to find the parent document.

– rmac
Dec 15 '18 at 15:11






2




2





Glad I found that. Everything are broken today on our side because of this.

– Brieuc
Dec 15 '18 at 15:28





Glad I found that. Everything are broken today on our side because of this.

– Brieuc
Dec 15 '18 at 15:28













3














I'm the Google employee working on the incident. There is a known compatibility issue for customers using the SDK when Firestore was in a private alpha and have not upgraded.



Could affected customers who are running their code with an SDK version newer than 0.6.2 respond? If you are running version 0.6.1 you can upgrade to 0.6.2 with no code changes to fix.






share|improve this answer
























  • Which SDK? The "firebase-functions" NPM package? This is an extract from our package.json: ``` "engines": { "node": "8" }, "dependencies": { "@google-cloud/storage": "2.3.1", "firebase-admin": "^6.3.0", "firebase-functions": "^2.1.0" } ```

    – rmac
    Dec 15 '18 at 16:58






  • 1





    the firebase-functions: 2.1.0 is what I was asking about. It seems like firebase-functions may no longer guard against this server change. We are continuing to roll back.

    – Thomas Bouldin
    Dec 15 '18 at 16:59











  • Ok thanks. FYI, I can see in our yarn.lock that we get "@google-cloud/firestore@^0.19.0" indirectly as well.

    – rmac
    Dec 15 '18 at 17:01













  • my dependencies: {"firebase-admin": "^6.0.0", "firebase-functions": "^2.1.0"}. And in the package-lock.json I can see this dependecy "@google-cloud/firestore": "0.16.1", same version required by firebase-admin.

    – iouhammi
    Dec 15 '18 at 17:49






  • 1





    I am using Node 8 as well. My app was down for pretty much the entire day yesterday (IST) and I was glued to my laptop trying to manually do everything that cloud function would do until I had to ask my clients to stop using the app for the last few hours. It's a new app and few clients are using us for their daily billing so it's a big issue if the app just stops working. App is working fine now though. Thanks for the help! Is there any advice on what to do if we face these kind of issues?

    – Nikhil Agarwal
    Dec 16 '18 at 4:14
















3














I'm the Google employee working on the incident. There is a known compatibility issue for customers using the SDK when Firestore was in a private alpha and have not upgraded.



Could affected customers who are running their code with an SDK version newer than 0.6.2 respond? If you are running version 0.6.1 you can upgrade to 0.6.2 with no code changes to fix.






share|improve this answer
























  • Which SDK? The "firebase-functions" NPM package? This is an extract from our package.json: ``` "engines": { "node": "8" }, "dependencies": { "@google-cloud/storage": "2.3.1", "firebase-admin": "^6.3.0", "firebase-functions": "^2.1.0" } ```

    – rmac
    Dec 15 '18 at 16:58






  • 1





    the firebase-functions: 2.1.0 is what I was asking about. It seems like firebase-functions may no longer guard against this server change. We are continuing to roll back.

    – Thomas Bouldin
    Dec 15 '18 at 16:59











  • Ok thanks. FYI, I can see in our yarn.lock that we get "@google-cloud/firestore@^0.19.0" indirectly as well.

    – rmac
    Dec 15 '18 at 17:01













  • my dependencies: {"firebase-admin": "^6.0.0", "firebase-functions": "^2.1.0"}. And in the package-lock.json I can see this dependecy "@google-cloud/firestore": "0.16.1", same version required by firebase-admin.

    – iouhammi
    Dec 15 '18 at 17:49






  • 1





    I am using Node 8 as well. My app was down for pretty much the entire day yesterday (IST) and I was glued to my laptop trying to manually do everything that cloud function would do until I had to ask my clients to stop using the app for the last few hours. It's a new app and few clients are using us for their daily billing so it's a big issue if the app just stops working. App is working fine now though. Thanks for the help! Is there any advice on what to do if we face these kind of issues?

    – Nikhil Agarwal
    Dec 16 '18 at 4:14














3












3








3







I'm the Google employee working on the incident. There is a known compatibility issue for customers using the SDK when Firestore was in a private alpha and have not upgraded.



Could affected customers who are running their code with an SDK version newer than 0.6.2 respond? If you are running version 0.6.1 you can upgrade to 0.6.2 with no code changes to fix.






share|improve this answer













I'm the Google employee working on the incident. There is a known compatibility issue for customers using the SDK when Firestore was in a private alpha and have not upgraded.



Could affected customers who are running their code with an SDK version newer than 0.6.2 respond? If you are running version 0.6.1 you can upgrade to 0.6.2 with no code changes to fix.







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 15 '18 at 16:46









Thomas BouldinThomas Bouldin

2,9941318




2,9941318













  • Which SDK? The "firebase-functions" NPM package? This is an extract from our package.json: ``` "engines": { "node": "8" }, "dependencies": { "@google-cloud/storage": "2.3.1", "firebase-admin": "^6.3.0", "firebase-functions": "^2.1.0" } ```

    – rmac
    Dec 15 '18 at 16:58






  • 1





    the firebase-functions: 2.1.0 is what I was asking about. It seems like firebase-functions may no longer guard against this server change. We are continuing to roll back.

    – Thomas Bouldin
    Dec 15 '18 at 16:59











  • Ok thanks. FYI, I can see in our yarn.lock that we get "@google-cloud/firestore@^0.19.0" indirectly as well.

    – rmac
    Dec 15 '18 at 17:01













  • my dependencies: {"firebase-admin": "^6.0.0", "firebase-functions": "^2.1.0"}. And in the package-lock.json I can see this dependecy "@google-cloud/firestore": "0.16.1", same version required by firebase-admin.

    – iouhammi
    Dec 15 '18 at 17:49






  • 1





    I am using Node 8 as well. My app was down for pretty much the entire day yesterday (IST) and I was glued to my laptop trying to manually do everything that cloud function would do until I had to ask my clients to stop using the app for the last few hours. It's a new app and few clients are using us for their daily billing so it's a big issue if the app just stops working. App is working fine now though. Thanks for the help! Is there any advice on what to do if we face these kind of issues?

    – Nikhil Agarwal
    Dec 16 '18 at 4:14



















  • Which SDK? The "firebase-functions" NPM package? This is an extract from our package.json: ``` "engines": { "node": "8" }, "dependencies": { "@google-cloud/storage": "2.3.1", "firebase-admin": "^6.3.0", "firebase-functions": "^2.1.0" } ```

    – rmac
    Dec 15 '18 at 16:58






  • 1





    the firebase-functions: 2.1.0 is what I was asking about. It seems like firebase-functions may no longer guard against this server change. We are continuing to roll back.

    – Thomas Bouldin
    Dec 15 '18 at 16:59











  • Ok thanks. FYI, I can see in our yarn.lock that we get "@google-cloud/firestore@^0.19.0" indirectly as well.

    – rmac
    Dec 15 '18 at 17:01













  • my dependencies: {"firebase-admin": "^6.0.0", "firebase-functions": "^2.1.0"}. And in the package-lock.json I can see this dependecy "@google-cloud/firestore": "0.16.1", same version required by firebase-admin.

    – iouhammi
    Dec 15 '18 at 17:49






  • 1





    I am using Node 8 as well. My app was down for pretty much the entire day yesterday (IST) and I was glued to my laptop trying to manually do everything that cloud function would do until I had to ask my clients to stop using the app for the last few hours. It's a new app and few clients are using us for their daily billing so it's a big issue if the app just stops working. App is working fine now though. Thanks for the help! Is there any advice on what to do if we face these kind of issues?

    – Nikhil Agarwal
    Dec 16 '18 at 4:14

















Which SDK? The "firebase-functions" NPM package? This is an extract from our package.json: ``` "engines": { "node": "8" }, "dependencies": { "@google-cloud/storage": "2.3.1", "firebase-admin": "^6.3.0", "firebase-functions": "^2.1.0" } ```

– rmac
Dec 15 '18 at 16:58





Which SDK? The "firebase-functions" NPM package? This is an extract from our package.json: ``` "engines": { "node": "8" }, "dependencies": { "@google-cloud/storage": "2.3.1", "firebase-admin": "^6.3.0", "firebase-functions": "^2.1.0" } ```

– rmac
Dec 15 '18 at 16:58




1




1





the firebase-functions: 2.1.0 is what I was asking about. It seems like firebase-functions may no longer guard against this server change. We are continuing to roll back.

– Thomas Bouldin
Dec 15 '18 at 16:59





the firebase-functions: 2.1.0 is what I was asking about. It seems like firebase-functions may no longer guard against this server change. We are continuing to roll back.

– Thomas Bouldin
Dec 15 '18 at 16:59













Ok thanks. FYI, I can see in our yarn.lock that we get "@google-cloud/firestore@^0.19.0" indirectly as well.

– rmac
Dec 15 '18 at 17:01







Ok thanks. FYI, I can see in our yarn.lock that we get "@google-cloud/firestore@^0.19.0" indirectly as well.

– rmac
Dec 15 '18 at 17:01















my dependencies: {"firebase-admin": "^6.0.0", "firebase-functions": "^2.1.0"}. And in the package-lock.json I can see this dependecy "@google-cloud/firestore": "0.16.1", same version required by firebase-admin.

– iouhammi
Dec 15 '18 at 17:49





my dependencies: {"firebase-admin": "^6.0.0", "firebase-functions": "^2.1.0"}. And in the package-lock.json I can see this dependecy "@google-cloud/firestore": "0.16.1", same version required by firebase-admin.

– iouhammi
Dec 15 '18 at 17:49




1




1





I am using Node 8 as well. My app was down for pretty much the entire day yesterday (IST) and I was glued to my laptop trying to manually do everything that cloud function would do until I had to ask my clients to stop using the app for the last few hours. It's a new app and few clients are using us for their daily billing so it's a big issue if the app just stops working. App is working fine now though. Thanks for the help! Is there any advice on what to do if we face these kind of issues?

– Nikhil Agarwal
Dec 16 '18 at 4:14





I am using Node 8 as well. My app was down for pretty much the entire day yesterday (IST) and I was glued to my laptop trying to manually do everything that cloud function would do until I had to ask my clients to stop using the app for the last few hours. It's a new app and few clients are using us for their daily billing so it's a big issue if the app just stops working. App is working fine now though. Thanks for the help! Is there any advice on what to do if we face these kind of issues?

– Nikhil Agarwal
Dec 16 '18 at 4:14


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53792140%2fcloud-functions-context-params-return-undefined%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Wiesbaden

Marschland

Dieringhausen