Closed sashatc closed 5 months ago
upon manually hacking processQueue to use "ext-send-message-" prefix for webhook callback URL all works ok, so the only issue is function getFunctionsUrl(functionName)
Oh, that sounds like something new. I'll take a look into it.
Thanks for letting me know!
@philnash are there any updates on this issue? We are also seeing errors in Twilio logs trying to call the statusCallback
endpoint, while the actual endpoint created by the extension is ext-send-message-statusCallback
.
Apologies, I've not had the chance to fix this yet. Also, I was recently affected by the recent Twilio layoffs so someone else from the team will have to look into it from now on.
Any updates on this issue? I'm testing the Twilio Firebase Extension and I am also seeing errors in Twilio logs trying to call the statusCallback endpoint, while the actual endpoint created by the extension is ext-send-message-statusCallback. Is there any workaround I can do meanwhile?
Hi @sprechu, as per the message above, I no longer work for Twilio and can’t help here.
Yes, I've got it ... I've opened a ticket on Twilio Support linking this issue thread ... hoping this will help. Thanks anyway for replying.
as a workaround - give Twilio what it wants (make sure you are doing it in the correct GCP project)
should do the trick, don't forget to verify all security access, secrets and ENV variables to be copied as well
Alternatively you can go and edit your original ext-send-message-statusCallback
getFunctionsUrl(functionName: string): string {
if (process.env.IS_FIREBASE_CLI) {
const baseUrl = process.env.HTTP_TUNNEL
? `https://${process.env.HTTP_TUNNEL}/`
: "http://localhost:5001/";
return `${baseUrl}${config.projectId}/${config.location}/${functionName}`;
} else {
return `https://${config.location}-${config.projectId}.cloudfunctions.net/${functionName}`;
}
}
change it to
getFunctionsUrl(functionName: string): string {
if (process.env.IS_FIREBASE_CLI) {
const baseUrl = process.env.HTTP_TUNNEL
? `https://${process.env.HTTP_TUNNEL}/`
: "http://localhost:5001/";
return `${baseUrl}${config.projectId}/${config.location}/${functionName}`;
} else {
return `https://${config.location}-${config.projectId}.cloudfunctions.net/ext-send-message-${functionName}`;
}
}
function getFunctionsUrl(functionName) {
if (process.env.IS_FIREBASE_CLI) {
const baseUrl = process.env.HTTP_TUNNEL
? `https://${process.env.HTTP_TUNNEL}/`
: "http://localhost:5001/";
return `${baseUrl}${config_1.default.projectId}/${config_1.default.location}/${functionName}`;
}
else {
return `https://${config_1.default.location}-${config_1.default.projectId}.cloudfunctions.net/${functionName}`;
}
}
to
function getFunctionsUrl(functionName) {
if (process.env.IS_FIREBASE_CLI) {
const baseUrl = process.env.HTTP_TUNNEL
? `https://${process.env.HTTP_TUNNEL}/`
: "http://localhost:5001/";
return `${baseUrl}${config_1.default.projectId}/${config_1.default.location}/ext-send-message-${functionName}`;
}
else {
return `https://${config_1.default.location}-${config_1.default.projectId}.cloudfunctions.net/${functionName}`;
}
}
Hi @sashatc, thanks for your help. I applied the workaround solution you suggestd (2nd option, ie. adding prefix ext-send-message- in utils.ts and utils.js) in the ext-send-message-statusCallack function, but nothing changes ... I needed to make the same modifications also in the ext-send-message-processQueue function to see finally the extension working correctly.
@sprechu I faced the same issues, after changing both utils.ts and utils.js, it still doesn't work. Able to share what modifications do you make in ext-send-message-processQueue function?
Managed to get it works, for others who faced the same issue, you need to go to back functions of processQueue & statusCallback, not the processqueue.js or processqueue.ts
fixed #101
Not sure if it is just me or this is smth new in how firebase extensions are deployed, but after installing via console Firebase has created functions with names prefixed with "ext-send-message-"
While it does not affect triggering processQueue function on document writes, it very much does so screws statusCallback URL formation and subsequent miss, resulting in twilio backend invoking wrong URL -> 400 Bad Request response.