catch errors during App Hosting deploys

[bkendall]

Description

Fixes #8866

Capturing the error during a deploy allows us to fail the deploy command.

Scenarios Tested

» firebase deploy --only apphosting

=== Deploying to 'PROJECT'...

i  deploying apphosting
i  apphosting: Found backend(s) BACKEND
✔ BACKEND is linked to the remote repository at REPO. Are you sure you want to deploy your local source? Yes
✔  Wrote /Users/bkend/Repositories/REPO/firebase.json
i  apphosting: On future invocations of "firebase deploy", your local source will be deployed to BACKEND. You can edit this setting in your firebase.json at any time.
i  apphosting: Creating Cloud Storage bucket in us-east5 to store App Hosting source code uploads at BUCKET...
i  apphosting: Zipped source for backend BACKEND
i  apphosting: Uploading source for backend BACKEND...
i  apphosting: Uploaded at gs://BUCKET/BACKEND--43201-njD4HbtmSAWJ-.zip
i  apphosting: You may also track the rollout(s) at:
	https://console.firebase.google.com/project/PROJECT/apphosting
⠹ Starting rollout(s) for backend(s) BACKEND; this may take a few minutes. It's safe to exit now.
^C
» firebase deploy --only apphosting

=== Deploying to 'PROJECT'...

i  deploying apphosting
i  apphosting: Found backend(s) BACKEND
i  apphosting: Zipped source for backend BACKEND
i  apphosting: Uploading source for backend BACKEND...
i  apphosting: Uploaded at gs://BUCKET/BACKEND--43257-GskP8ryv4KE1-.zip
i  apphosting: You may also track the rollout(s) at:
	https://console.firebase.google.com/project/PROJECT/apphosting
⠹ Starting rollout(s) for backend(s) BACKEND; this may take a few minutes. It's safe to exit now.
⚠  apphosting: Rollout for backend BACKEND failed.
⬢  apphosting: FirebaseError: Request to https://firebaseapphosting.googleapis.com/v1beta/projects/PROJECT/locations/us-east5/backends/BACKEND/builds?buildId=build-2026-02-26-005 had HTTP Error: 409, unable to queue

Error: One or more rollouts failed. Please review the errors above and try again.
» echo $?
1

[gemini-code-assist]

Summary of Changes

Hello @bkendall, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the robustness of App Hosting deployments by integrating comprehensive error detection for backend rollouts. The primary goal is to prevent silent failures, ensuring that the deployment command accurately reflects the success or failure of the underlying rollout processes. This improves the reliability of the deployment workflow and provides clearer feedback to users.

Highlights

• Improved Error Handling: The App Hosting deployment process now explicitly catches and reports errors during backend rollouts. Previously, the firebase deploy command could complete successfully even if a rollout failed, leading to a misleading success state. This change ensures that any rollout failure results in a FirebaseError, causing the deploy command to fail as expected.
• Enhanced User Feedback: Users will now receive immediate feedback if an App Hosting backend rollout fails, with a clear error message indicating that one or more rollouts have failed and prompting them to review the errors.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• CHANGELOG.md
  • Detects when App Hosting fails to deploy, returning an error. (Failed App Hosting rollout prints "Deploy complete!" #8866)

Activity

• The pull request was created by bkendall to address issue Failed App Hosting rollout prints "Deploy complete!" #8866, focusing on catching errors during App Hosting deploys.
• The author provided detailed scenarios tested, demonstrating how the firebase deploy --only apphosting command now correctly reports failures when rollouts encounter issues, such as HTTP 409 errors.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly adds error handling for failed App Hosting rollouts, ensuring the deploy command fails as expected. I've added a couple of suggestions to improve the error logging by using an existing utility function, which makes the error messages more robust and aligns better with the repository's best practices.

[gemini-code-assist]

To enable more robust error message handling later in the file, please also import getErrMsg here.

Suggested change

	import { FirebaseError } from "../../error";
	import { FirebaseError, getErrMsg } from "../../error";

[gemini-code-assist]

Using getErrMsg provides more robust error message extraction from the unknown type res.reason. It correctly handles Error objects, strings, and other types, preventing potential output like [object Object]. This also aligns with our best practice of not using escape hatches for unknown types.

Suggested change

	logLabeledError("apphosting", `${res.reason}`);
	logLabeledError("apphosting", getErrMsg(res.reason));

References

1. The style guide recommends against using escape hatches for any or unknown types and instead using proper interfaces, types, or type guards. Using getErrMsg is a better way to handle the unknown error reason. ^(link)