-
Notifications
You must be signed in to change notification settings - Fork 900
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allUsers > Cloud Functions Invoker role randomly added to newly deployed HTTP functions #3965
Comments
Do you have a log file for when this happens? That would help greatly in trying to debug this. I'm not sure off hand of an issue where this would only occasionally work but maybe there's something that can help shed light on it. |
Hey @feliksmatsko. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically. If you have more information that will help us get to the bottom of this, just add a comment! |
Since there haven't been any recent updates here, I am going to close this issue. @feliksmatsko if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this. |
We can add more retries to this API call, but it tends to just be flaky. If you set |
Implemented fix for issue introduced in `v10.3.0` where callable functions were not having their `invoker` property correctly set to `"public"` that would in turn cause access issues with the deployed functions (as detailed in #4327). Will also fix issues such as #3965, that are presumably cause by version mismatches/upgrades introducing this issue. Fixes issue by adding specific handling for callable functions and always setting the `invoker` to `"public"`. Also fixed issue with `taskQueueTrigger` endpoints calling wrong method/passing wrong args when trying to set invoker.
Implemented fix for issue introduced in `v10.3.0` where callable functions were not having their `invoker` property correctly set to `"public"` that would in turn cause access issues with the deployed functions (as detailed in #4327). Will also fix issues such as #3965, that are presumably cause by version mismatches/upgrades introducing this issue. Fixes issue by adding specific handling for callable functions and always setting the `invoker` to `"public"`. Also fixed issue with `taskQueueTrigger` endpoints calling wrong method/passing wrong args when trying to set invoker.
Environment info
firebase-tools: 10.0.1
Platform: macOS
Test case
https://github.com/feliksmatsko/firebase-cli-issue
Steps to reproduce
Expected behavior
For ALL newly deployed cloud functions to have the same permissions
Actual behavior
Some functions allow authenticated and some don't. The number of functions with and without invoker created is random.
Multiple errors in cli: "Error Failed to set invoker function f38 in region us-central1"
The text was updated successfully, but these errors were encountered: