Making onCall Dart functions Public when deployed

[shettyvarun268]

Fixes #10225

This Pull Request ensures that newly deployed Gen 2 Dart callable functions correctly default to public access on Cloud Run instead of requiring authentication by default.

[gemini-code-assist]

Code Review

This pull request updates the Fabricator class in src/deploy/functions/release/fabricator.ts to support callable-triggered functions. It adds logic to identify these endpoints and uses the executor to set their IAM invoker permissions to public via the run.setInvokerUpdate method. I have no feedback to provide.

[ajperel]

I think we probably want to be consistent with Node here. I was asking an agent to compare the two implementations (because I'm assuming Node is doing the right things) and I think there are additional bugs in the behavior (though not caused by you, still something we should fix and just get it right at once). Here's a lightly edited summary from an agent:

---

I reviewed your recent commits regarding Dart function visibility and noticed a few inconsistencies between the new Dart behavior and the existing Node (GCFv1/v2) behavior. To ensure a consistent developer experience across runtimes, we should align them.

Here are the two main areas to address:

1. Callable Functions Visibility on Update

• Node Behavior: Node functions are made public on creation, but on update, the CLI does not touch the IAM policy for Callable functions. This allows users to manually make them private in the console if needed, without the CLI reverting it.
• Current Dart Behavior: In setInvoker (called by both createRunFunction and updateRunFunction), Callable functions are forced to ["public"] on every deploy.
• The Issue: If a user manually makes a Dart Callable function private in the Google Cloud Console, a subsequent firebase deploy will force it back to public.
• Suggested Fix: Update setInvoker to only set the invoker to ["public"] for Callable functions during creation, not on update.

2. Updating HTTPS Functions to Private

• Node Behavior: Node functions allow specifying invoker: ["private"] to remove public access. On update, updateV2Function calls run.setInvokerUpdate with ["private"], which correctly removes allUsers and makes the function private.
• Current Dart Behavior: In setInvoker for HTTPS triggers, there is a check if (!invoker.includes("private")) before calling run.setInvokerUpdate.
• The Issue: If a user explicitly configures invoker: ["private"] for a Dart HTTPS function to remove public access, setInvoker will skip calling run.setInvokerUpdate. This means a previously public function will remain public on update.
• Suggested Fix: Remove the !invoker.includes("private") check on update so that setting it to private actually takes effect by removing allUsers (which setInvokerUpdate handles correctly when passed ["private"]).

---

I notice for all the other languages they use separate methods for create & update which allows there to be fairly separate logic. We could go that route for dart too? Or make a better setInvoker method?

Thoughts?

[shettyvarun268]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the invoker configuration logic by inlining the previously shared setInvoker method into createRunFunction and updateRunFunction. While createRunFunction now correctly handles both HTTPS and callable triggers, the updateRunFunction implementation is missing the logic for callable triggers and the check to respect private invoker settings. Additionally, feedback suggests adding unit tests to verify the new callable trigger logic during function creation to ensure comprehensive test coverage.

[shettyvarun268]

Great points, Andy! The Dart block did things slightly differently to save code lines, but that shared method is exactly what caused these bugs to sneak into updates.

I have removed the shared setInvoker method exclusively created for Dart. While inlining instructions creates slightly longer files, it eliminates the update bugs you raised and brings in the semantic consistency with the Node and Python sections in this file

I also updated the test suite stubs to listen for setInvokerCreate to account for this newly refactored creation flow.

[ajperel]

Thanks for adding tests too!

[ajperel]

If you look at v2 update ~line 603 you'll notice they do it slightly differently

invoker = endpoint.httpsTrigger.invoker === null ? ["public"] : endpoint.httpsTrigger.invoker;

This is distinguishing between null and undefined

AI calls out this difference:

HTTPS Functions: They are aligned on creation, but there is a difference on update:

• Node (updateV2Function): If the invoker field is omitted (undefined), it does not touch the IAM policy. If it is explicitly set to ["public"] or ["private"], it updates it.
• Dart (updateRunFunction): If the invoker field is omitted (undefined), it falls back to ["public"] and calls setInvokerUpdate.

Impact of the difference: If a user manually makes a Dart HTTPS function private in the Cloud Console and does not specify invoker in their configuration, the next firebase deploy will force it back to public. For Node, it would stay private.

We're getting close to very duplicated code between Dart and gen2. I think since we only handle 2 event types that duplication is maybe OK for now. But we should consider unifying the invoker logic to only be in one place in the future. Otherwise it'll be really easy to again subtly introduce bugs like this. Or we do it now and have more complex logic for only supporting a subset of triggers for Dart.

[ajperel]

Code changes look good. Can you also add tests. Mostly for Dart, but it looks like we could also use a test for Node that ensures the null vs undefined behavior on update.

[ajperel]

Can you add one last test for https where we've explicitly configured it to private for the invoker.

[ajperel]

Some lint issues to fix but LG.

[wandamora]

LGTM!