fix(antigravity): wrap Pro fallback chain in try/catch for timeout resilience

[HouMinXi]

Problem

When gemini-3.1-pro-high returns HTTP 400, the Pro fallback chain should retry with alternative model IDs (gemini-pro-agent, gemini-3-pro-high). However, if a subsequent candidate hangs and times out, the exception escapes the fallback loop and the remaining candidates are never tried.

Reproduction: Request gemini-3.1-pro-high → 400 → retry gemini-pro-agent → timeout → exception escapes → gemini-3-pro-high never attempted. User sees 120s timeout instead of a response.

Fix

Wrap executeOnce() in try/catch within the Pro fallback loop (execute() method):

• Non-last candidates: log debug message and continue to next candidate
• Last candidate: throw wrapped error with "chain exhausted" context for diagnostics
• Abort signal: propagate immediately (no wasted requests after client disconnect)

Tests

3 new test cases in agy-pro-fallback-chain-3786.test.ts:

1. Exception on first candidate, second returns 200 → fallback succeeds
2. All candidates throw → error includes "chain exhausted"
3. Mixed: 400 on first, exception on second, 200 on third → reaches third

All 11 tests pass (8 existing + 3 new).

Verification

• MCP code-forge review: PASS (deepseek-v4-flash, 3 passes)
• MCP code-review-graph: risk 0.00, 0 affected flows
• Hotfix deployed to production OmniRoute: gemini-3.1-pro-high now completes in ~3s instead of hanging 120s

[gemini-code-assist]

Code Review

This pull request implements exception handling and retry logic within the Pro fallback chain of the AntigravityExecutor, allowing the execution to fall back to subsequent candidates when an exception occurs, while immediately propagating abort signals. It also adds comprehensive unit tests to verify these behaviors. The review feedback suggests improving the abort signal detection to support standard Error objects with an "AbortError" name, and refining the final error handling when the chain is exhausted to return a prior 400 response if one exists, rather than throwing a generic error.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

To ensure maximum robustness across different environments, shims, or test mocks (which might throw a standard Error with name: "AbortError" instead of a true DOMException), we should also check if error is an instance of Error with name === "AbortError".

        const isAbort = 
          input.signal?.aborted || 
          (error instanceof DOMException && error.name === "AbortError") || 
          (error instanceof Error && error.name === "AbortError");
        if (isAbort) {
          throw error;
        }

[gemini-code-assist]

There are two issues here:

1. The error message states that all ${chain.length} candidates threw, which is misleading if some candidates returned a 400 response instead of throwing an exception (e.g., in a mixed path scenario).
2. If the first candidate returned a 400 response (stored in firstResult), returning firstResult is much more consistent and robust than throwing a hard 500 error. This matches the behavior of the all-400 case below where we return firstResult to surface the original sanitized error to the client.

        // Last candidate also threw -- wrap all-failed context or return original 400 if available.
        if (firstResult) {
          input.log?.warn?.(
            'AG_PRO_FALLBACK',
            'Pro fallback chain exhausted (last candidate threw, but first candidate returned 400) for "' + resolvedUpstreamId + '". Returning original 400.'
          );
          return firstResult;
        }
        throw new Error(
          'Pro fallback chain exhausted (all ' + chain.length + ' candidates failed). Last error: ' + (error instanceof Error ? error.message : String(error))
        );

[diegosouzapw]

Thanks for this — the try/catch resilience fix for the Pro fallback chain is well-reasoned and I traced the call graph to confirm it only retries pre-response (before any bytes reach the client), so it doesn't violate our no-swallow-in-SSE-streams rule, and the "chain exhausted" error message flows through our existing sanitization path correctly. All 13 tests in agy-pro-fallback-chain-3786.test.ts pass locally (8 existing + 5 new across your commits).

One gap before merge: the src/mitm/dns/provision.ts container-skip fix (canElevate()/SKIP_ANTIGRAVITY_DNS) has no test coverage — mitm-dns-graceful-degrade-6127.test.ts wasn't updated to exercise either new branch. We'll add that test in your branch (Hard Rule #18 in our contributing guide requires it) so we can merge as-is otherwise. Also worth noting for next time: that DNS fix is unrelated to the PR title/description — separating unrelated fixes into their own PRs makes review/rollback cleaner, though we're happy to take both here.

[diegosouzapw]

Thanks @HouMinXi! Merged into release/v3.8.49 after merge-train validation on the combined tree. The fallback-chain try/catch was split into the proFallbackChain module to clear the complexity gates — authorship preserved.