After deploy Cloud Functions error: Could not refresh access token. - node.js

I've been experimenting for a while with Firebase Cloud Functions, today I made a minor change to my index.json file (added a field to a document to be set), after deploying on the Firebase Console > Functions > Logs I've got this weird errors:
Auth error:Error: Could not refresh access token.
and:
Error: 16 UNAUTHENTICATED: Getting metadata from plugin failed with error: Could not refresh access token.
at new createStatusError (/user_code/node_modules/firebase-admin/node_modules/grpc/src/client.js:65:15)
at /user_code/node_modules/firebase-admin/node_modules/grpc/src/client.js:568:15
Here's a list of things I tried but did not work:
revert the change in index.json
deploy every function (made the problem worse, now none of my cloud functions is working)
generate a new keyFilename for #google-cloud/storage
npm update firebase-admin
(rebooting)
The last time I did a firebase deploy successfully was last night.
I'm on linux.
Thank you.

Thanks everyone for the reports, both here and especially also via our tech support channels - these really help.
We believe the issue to have been caused by a problem deep in our Node.js dependency chain, in particular for users of Firestore. We've just released https://www.npmjs.com/package/google-gax 0.14.5 to address the issue. Please:
Either wait for the npm caches to pick up the new version, or explicitly request google-gax 0.14.5 in your package.json.
Re-deploy your functions.
That should resolve things. If you're still having trouble, please let us know!

Our current suspicion is that a very nested dependency had a breaking change that didn't follow semver. We're investigating and hope to have a fix soon. When this fix rolls out, you'll only have to redeploy.

Related

Reinstall Shopify App Error: "The Page is not Avalaible

I am developing the shopify app according to the tutorial presented on the page (QR create code), however when I am doing tests, when I uninstall it and try to reinstall it I get the following message:
There is no page at this address
Please check the URL and try again, or use the search bar to find what you need. (Attached in the photo)
Photo 404
If you can help me, thank you very much, I feel that it is as if the authentication failed or I had already used the token, the truth is that I do not know about the subject
My project is in node, react
"#shopify/app": "3.3.3",
"#shopify/cli": "3.3.3"
Thanks
This is a shopify_app bug
You need to delete the previous installation Shop from the database then try the install again and it will work.
If you have only one shop in the database quick solution will be the rails console
rails c
Shop.first.destroy
To resolve it permanently you have to register and handle the app_uninstalled webhook however it will not work 100% of the time due to delay. When the user removes the app the Shopify server trigger webhook with delay (2 seconds to 10 minutes)

Maximum call stack size exceeded when using Nestjs validation pipeline with form-data (Fastify)

since the owner just closed my issue on GitHub and the people on the official discord server couldn't help me, I'm trying my luck here.
Since NestJS doesn't have interceptors or anything else for fastify (for file uploads), I wanted to use the fastify-multipart (now #fastify/multipart) package. I registered the middleware the normal way, but I'm using the attachFieldsToBody option, so I can properly use the validation pipeline which I've set to global. I have a very simple setup with a DTO for my post request. If you let the sandbox container run, you'll see the 500 error saying maximum call stack exceeded which happened in the validation pipeline.
GitHub Issue: https://github.com/nestjs/nest/issues/9683
Sandbox: https://codesandbox.io/s/nestjs-fastify-multipart-bug-17m5ls
The multipart middleware works fine (even though someone on Discord thought that was an issue, assuming that I didn't google for it). The only issue is the validation pipeline, but I can't track this down, I'm unsure why it causes an infinite loop. While I'm debugging and looking through the common package source code, if anyone ran into this issue or has an idea for a solution, please let me know.

Gitlab Pages 502 problem after v13->v14 upgrade

We’ve just upgraded GitLab v13 to v14 and have encountered some problems with our gitlab-pages config. Pages was working fine with v13, but with v14 we are now getting 502 errors when attempting to access the hosted pages. (We did follow the upgrade path to 13.12.x before upgrading to v14.)
The error seems to be ca-cert/authority related. The last entry in /var/log/gitlab/gitlab-pages/current is
{“error”:“failed to connect to internal Pages API: Get “https://gitlab-vm.intranet/api/v4/internal/pages/status”:
x509: certificate signed by unknown authority”,“level”:“warning”,“msg”:“attempted to connect to the API”,“time”:“2021-07-08T10:35:35Z”}
Here, gitlab-vm is the server name of the VM hosting gitlab and gitlab-pages, but our pages are accessed at https://project.gitlab-pages.intranet. I diddn’t expect the name of the machine to appear in the api url (in the log entry above), but nevertheless the ‘unknown authority’ rather than a ‘cert not found’ type message would tend to suggest that paths are resolving correctly and that it’s an issue with the ca itself (which was previously working fine).
Has anything changed with regard to how CAs / certs are handled in GitLab v14, in particular w.r.t. the API?
Any pointers to where to start looking to fix this would be much appreciated.
After applying the update to 14.2.1 (from 14.0.4) the issue with gitlab-pages appears to be fixed.

Azure SignalR: HubException method does not exist

I am finding we receive this error:
Failed to invoke 'CreateChatRequest' due to an error on the server. HubException: Method does not exist.
at _this.callbacks.<computed> (chat.min.js:2060)
at HubConnection.processIncomingData (chat.min.js:2154)
at WebSocketTransport.HubConnection.connection.onreceive (chat.min.js:1881)
at WebSocket.webSocket.onmessage (chat.min.js:3922)
The method does exist. The code does work, then after a while of testing, it returns this and won't stop.
What seems to temporarily fix the issue is restarting the Azure SigR service, but it comes back. This issue does not occur when targeting local SigR during development; it only happens against Azure SigR.
According to documentation, this seems to be a catchall error when something errors up on the server but, no exceptions are being logged. I've turned on detailed errors, but that didn't change the error coming back from the server. I've also tried catching the exception and sending back a HubException to see what is going on, but that didn't change the error message either.
TIA for any help.
So the answer, for me, was that i'd checked in (to source control) my azure service's connection string, so other devs were also using this and pointing their versions of the API service at that azure service. So when i ran my code sometimes azure would hit my API service with the new method in and it would work, sometimes it would hit someone else's API service and so fail because their code didn't have the new method in.

Sudden forbidden access

Since this morning, all our ChatBot using DialogFlow get denied with a response code 403 and the following JSON :
{"status":{"code":401,"errorType":"unauthorized","errorDetails":"You are not authorized for this operation. Invalid access token"}}
We tried to update the client access token for one of them but without any change.
Note that the responseCode is different that the one specified in the JSON.
Any idea?
Could be an issue with the service itself. There is already a thread in the official community forum:
https://productforums.google.com/forum/#!topic/dialogflow/CEZE6HS4C4o;context-place=forum/dialogflow
You are not alone...
I tried what Andrey Kotkovets said in this thread: https://productforums.google.com/forum/#!topic/dialogflow/CEZE6HS4C4o;context-place=forum/dialogflow
and it worked. You need to export your bots and import them as v1 for now.
edit: I created new agents and imported the old ones, I didn't overwrite the old ones.

Resources