Starter deployment failed; production unavailable and rollback disabled

Google AI Studio
1

Title: Google AI Studio Starter Deployment Failed — Please Locate Failed Operation and Provide a Supported Path to Roll Back to Previous Revision

I have encountered two issues in the Google AI Studio Starter managed environment that require separate investigation.

Applications and Resources:

  • AI Studio App ID: 36991f73-b34e-4c4f-b45b-1d481c5b0…
  • Google-managed Starter Project: endless-theater-lj1d7
  • Project Number: 10825498800..
  • Cloud Run Service: mbi-ai
  • Region: asia-south1
  • Last Verified Working Revision: mbi-ai-00024-tk..
  • Current Revision: mbi-ai-00025-t..
  • Affected Domains: httpsmbi-ai-1.ai.studio/ and httpsmbi-ai.ai.studio/
  1. Fourth Publish Failed; No Recovery Revision Generated

On 2026-10-01 (JST, UTC+09:00) at 14:53:35, “Republish” was clicked, and deployment confirmation was completed at 14:54:31. Around 14:58, the official console displayed “Failed to publish app.” Subsequent deployment attempts were halted.

The diagnostic window is 2026-10-01 05:52–06:06 UTC (14:52–15:06 JST). As of 18:56 JST, the most recently created and ready revision remains 00025, serving 100% of traffic, with no new recovery revision generated.

Official Read-Only Query Results:

  • Cloud Run service and revision metadata are readable.
  • operations.list using parent/name:
    projects/endless-theater-lj1d7/locations/asia-south1
    After removing filters, a single bounded request with pageSize=100 was executed, with returned fields excluding Operation.response, service configuration, and environment values. It still returned HTTP 400 INVALID_ARGUMENT, yielding neither pagination nor an operation ID. The query was incomplete; no repeated attempts were made.
  • Activity/system_event audit queries scoped to the service and failure window returned no matching records; this does not prove that the internal deployment workflow was not initiated.
  • A previous Cloud Build query returned HTTP 403 PERMISSION_DENIED, preventing retrieval of the build ID or the failure phase. No additional build permissions were requested, nor were IAM policies modified.

Currently, it cannot be determined whether the fourth deployment failed during packaging, building, deployment submission, or another pre-stage. Diagnostic query errors are not confirmed root causes of the deployment failure.

  1. Revision 00025 Sync Authentication and Active Snapshot Loading Failure

This issue predates the fourth attempted recovery deployment and should be isolated separately.

Authorized empty-payload authentication checks on both domains returned 401 unauthorized_invalid_secret, without triggering business syncs or database writes. Previous public endpoint re-verification:

  • Today: DATA_NOT_READY, store count: 0
  • Stores: Empty array, data for the original three stores unavailable
  • History: 404 HISTORY_ENDPOINT_UNAVAILABLE

Re-verified Health/sync/status at 18:54 JST:

  • has_active_snapshot=false
  • export_id=null
  • store_count=0
  • demo_mode=false

Although Health returns HTTP 200/status=ok, it cannot be considered a successful recovery.

A read-only inspection of the actual database loading chain shows that both the current pointer and the associated snapshot exist, and Today, store, and nested History data are readable. These records predate the creation of 00025 by approximately two hours; current readability does not verify that access succeeded at startup.

The existing status endpoints only indirectly show that the snapshot client object was created, without providing dedicated presence fields, hydration stages, or error codes for startup configuration items. The sync authentication error only allows inferring that the server-side comparison value is non-empty, but cannot confirm that the actual binding is correct.

Queries targeting the 00025 startup window and selected structured fields returned no matches, and log payloads were not retrieved; this does not imply that raw logs do not exist. Current observability is insufficient to confirm the actual startup bindings or the failure phase during loading. Offline testing cannot substitute for production evidence.

Recovery Capabilities and Requests:

The official Cloud Run revisions list still displays 00024 and 00025, but the “Manage Traffic” button is disabled for the current Starter account. Restoring source code checkpoints in the AI Studio console does not constitute a deployment revision rollback; no self-service deployment rollback option under Starter has been verified.

Please address the following:

  1. Locate the actual deployment operation/build ID during the failure window, providing the phase, timestamp, status, and non-sensitive error codes, and verify the deployment mapping between the original application and the existing service.
  2. Provide a supported path under Starter to retain the original application, service, and domains while rolling back to mbi-ai-00024-tk4, preferably without requiring a new deployment. If an action by Google administrators is required, please provide a proposal for confirmation by the application owner first.
  3. For revision 00025, provide non-sensitive startup binding/resource identity verification, along with the actual phase and error codes for hydration_select_pointer, hydration_select_snapshot, or hydration_select, without disclosing secret values or raw logs.

Please preserve all source code, credentials, and business data. Do not replace recovery with a new project, new service, unpublishing, billing tier upgrades, standard IAM permission grants, or repeated republish attempts.

Recovery acceptance criteria must cover authorized authentication on both domains, as well as data consistency across the active snapshot, Today, Stores, History, Health, and the original three stores; a revision being Ready or returning HTTP 200 alone is insufficient proof of recovery.

This submission contains no credentials, snippets, test accounts, personal email addresses, raw logs, or screenshots.