fix(oauth): antigravity login no longer hangs — fire-and-forget onboarding + bounded post-exchange

[diegosouzapw]

Problem

The dashboard Antigravity OAuth login "just spun forever" and never completed. Validated against the working 9router web flow (_references/_sistemas_proxys/9router).

Root cause

postExchange in src/lib/oauth/providers/antigravity.ts awaited the onboardUser retry loop inline (up to 10×5s, each fetch with no timeout), so a slow/unreachable Antigravity upstream blocked the /exchange response indefinitely. 9router's web flow runs the same onboarding fire-and-forget.

Fix

• onboardUser → fire-and-forget (void onboardInBackground().catch(...)): it never gates the OAuth login response. Project onboarding is also done lazily at request time by antigravityProjectBootstrap.ts, so backgrounding it is safe (matches 9router).
• userInfo + loadCodeAssist → AbortSignal.timeout(8s)-bounded (one shared deadline per fallback list, not per-endpoint — per-endpoint re-introduced a ~40s wait). Worst case ~16s, never infinite. Mirrors the existing antigravityProjectBootstrap.ts pattern.

Validation

• TDD: tests/unit/antigravity-oauth-postexchange-nonblocking.test.ts (2/2). postExchange returns in ~96ms with onboarding gated open; flip-proof: reverting to inline await hangs the test (EXIT 124). Timeout-bounded test confirms no infinite hang when upstreams stall.
• Live VPS: deploying to 192.168.0.15 for a real login validation (recorded below once done).

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request addresses a potential hang in the Antigravity OAuth login flow by making the onboarding process fire-and-forget and bounding all upstream requests with an 8-second timeout. It also adds unit tests to guard against regressions. The reviewer feedback highlights a potential crash if the user info response contains invalid JSON, points out that the background onboarding loop incorrectly terminates on any error instead of retrying, and suggests mocking AbortSignal.timeout in the unit tests to significantly speed up test execution.

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]

If the userInfo request succeeds but the response body is invalid JSON or empty, calling userInfoRes.json() will throw an unhandled exception and crash the entire postExchange (and thus the OAuth login) flow. Wrapping both the fetch and the JSON parsing in a single try-catch block ensures that any network, timeout, or parsing errors are safely caught and handled gracefully.

    let userInfo = {};
    try {
      const userInfoRes = await fetch(`${ANTIGRAVITY_CONFIG.userInfoUrl}?alt=json`, {
        headers: { Authorization: `Bearer ${tokens.access_token}` },
        signal: AbortSignal.timeout(POSTEXCHANGE_TIMEOUT_MS),
      });
      if (userInfoRes.ok) {
        userInfo = await userInfoRes.json();
      }
    } catch (e) {
      console.log("Failed to fetch user info:", e);
    }

[gemini-code-assist]

Breaking the loop on any error (catch { break; }) means that if the first onboarding attempt fails (e.g., due to a temporary network issue or a timeout), the background process will immediately stop retrying. Since the goal of this background loop is to retry up to 10 times, we should log the error and let the loop continue to the next iteration after the 5-second delay.

Suggested change

	} catch {
	break;
	}
	} catch (e) {
	console.log("Onboarding attempt failed:", e);
	}

[gemini-code-assist]

To prevent the unit tests from taking up to 16 seconds to run due to real timeouts, we can mock AbortSignal.timeout to use a much shorter duration during the test. Let's store the original AbortSignal.timeout and restore it in afterEach.

const originalFetch = globalThis.fetch;
const originalTimeout = AbortSignal.timeout;

function jsonRes(body: unknown, status = 200): Response {
  return new Response(JSON.stringify(body), {
    status,
    headers: { "Content-Type": "application/json" },
  });
}

// A fetch that rejects when its AbortSignal fires, and otherwise never resolves.
// Mirrors real fetch: an already-aborted signal rejects immediately (so a shared
// deadline reused across fallback endpoints fails fast after the first abort).
function stalledFetch(init?: { signal?: AbortSignal }): Promise<Response> {
  return new Promise((_resolve, reject) => {
    const abortErr = () => new DOMException("The operation was aborted.", "AbortError");
    const signal = init?.signal;
    if (signal?.aborted) {
      reject(abortErr());
      return;
    }
    signal?.addEventListener("abort", () => reject(abortErr()));
  });
}

test.afterEach(() => {
  globalThis.fetch = originalFetch;
  AbortSignal.timeout = originalTimeout;
});

[gemini-code-assist]

By mocking AbortSignal.timeout to a short duration (e.g., 50ms), we can speed up this test from ~16 seconds to ~100ms, and assert a much tighter timeout bound (e.g., < 1000ms instead of < 22000ms).

Suggested change

	test("postExchange stays timeout-bounded when loadCodeAssist/userinfo stall (no infinite hang)", async () => {
	globalThis.fetch = (async (url: unknown, init?: { signal?: AbortSignal }) => {
	const u = String(url);
	if (u.includes("userinfo") || u.includes("loadCodeAssist")) return stalledFetch(init);
	return jsonRes({});
	}) as typeof fetch;
	const start = Date.now();
	const result = await antigravity.postExchange({ access_token: "tok" } as never);
	const elapsed = Date.now() - start;
	// userInfo + loadCodeAssist are AbortSignal.timeout(8s)-bounded (one shared
	// deadline each), so the worst case is ~16s — never an infinite hang.
	assert.ok(elapsed < 22000, `postExchange must be timeout-bounded; took ${elapsed}ms`);
	assert.equal(result.projectId, "", "no project when loadCodeAssist times out");
	});
	test("postExchange stays timeout-bounded when loadCodeAssist/userinfo stall (no infinite hang)", async () => {
	AbortSignal.timeout = () => originalTimeout(50);
	globalThis.fetch = (async (url: unknown, init?: { signal?: AbortSignal }) => {
	const u = String(url);
	if (u.includes("userinfo") || u.includes("loadCodeAssist")) return stalledFetch(init);
	return jsonRes({});
	}) as typeof fetch;
	const start = Date.now();
	const result = await antigravity.postExchange({ access_token: "tok" } as never);
	const elapsed = Date.now() - start;
	// userInfo + loadCodeAssist are AbortSignal.timeout(8s)-bounded (one shared
	// deadline each), so the worst case is ~16s — never an infinite hang.
	// With AbortSignal.timeout mocked to 50ms, this runs in ~100ms.
	assert.ok(elapsed < 1000, `postExchange must be timeout-bounded; took ${elapsed}ms`);
	assert.equal(result.projectId, "", "no project when loadCodeAssist times out");
	});

[diegosouzapw]

🚀 Deployed to VPS 192.168.0.15 for live validation

build:release → dist/BUILD_SHA = 6c7bf7489 (== HEAD)
backup:        dist.bak-3.8.39-7b139fdb5 (prev live SHA)
rsync dist/ → /usr/lib/node_modules/omniroute/dist/  → VPS BUILD_SHA now 6c7bf7489
pm2 delete + start omniroute -- --port 20128
health: { "status": "healthy", "version": "3.8.39" }   HTTP 200

The fix bundle is live (BUILD_SHA matches this commit; auth-gated endpoints return the expected 307/401). Final step — operator login test: open http://192.168.0.15:20128/dashboard/providers/antigravity → Connect → complete Google OAuth and confirm the login completes instead of spinning. Rollback ready: dist.bak-3.8.39-7b139fdb5.

[diegosouzapw]

🚀 Deploy #2 to VPS 192.168.0.15 — no-PKCE/no-openid + fire-and-forget + paste UX

BUILD_SHA ab1813ff3 (== HEAD)   backup: dist.bak-3.8.39-6c7bf7489
rsync dist/ → VPS BUILD_SHA ab1813ff3
pm2 delete+start → health { status: healthy, version: 3.8.39 } HTTP 200

Root cause was the Google consent hang on signin/oauth/firstparty/nativeapp: our antigravity flow sent a PKCE code_challenge + the openid scope on a Desktop/native Google client. Now matches the working 9router flow (plain authorization_code, client_secret, no openid). Awaiting operator login validation on the VPS.

[diegosouzapw]

Deploy #3 (ea204bd) + definitive remote-OAuth findings

Shipped: exchange-500 fix (stop forwarding code_verifier on the now-PKCE-less antigravity grant). VPS ea204bd0b, health healthy.

Live-validated root cause of the remote hang (via Claude-in-Chrome):

• The Antigravity Google client triggers Google's first-party signin/oauth/firstparty/nativeapp consent ("Confira se você fez o download desse app pelo Google").
• After approval, that consent does a loopback handshake to the redirect_uri port and hangs if the loopback is unreachable. Tested both http://127.0.0.1:PORT and http://localhost:PORT with an unreachable port → both hang (so it is NOT a 127.0.0.1-vs-localhost issue). With the loopback reachable (SSH tunnel) the consent completes and redirects normally.
• Consequence: on a VPS reached by LAN/public IP the loopback lands on the operator's own machine → hang → no redirect → the manual copy-paste fallback can't work either (no URL is ever produced). This differs from Claude/Codex/gemini-cli, whose clients don't trigger this interstitial.
• This is a Google-side anti-abuse behavior (likely tightened recently); there is no OmniRoute code fix that bypasses it with the embedded native client.

Working remote options: (1) SSH tunnel so the loopback is reachable (ssh -L 20128:localhost:20128 root@VPS, then use 127.0.0.1:20128); (2) custom Google Web OAuth creds + NEXT_PUBLIC_BASE_URL (Web client ≠ native → standard consent, no loopback) — already supported via resolveBrowserOAuthRedirectUri.

The no-PKCE/no-openid + fire-and-forget + paste-instruction changes remain valid (align to 9router); they were necessary but not sufficient for remote.

[KooshaPari]

#5200 is ready to merge as the Fast Quality Gates unblocker.

Evidence:

• fix(5193): shrink file-size freeze offenders #5200 is mergeable and its semgrep-cloud-platform check is green
• local validation on KooshaPari:fix/5193-file-size-freeze:
  • npm run check:file-size
  • env DISABLE_SQLITE_AUTO_BACKUP=true node --max-old-space-size=8192 --import tsx --import ./open-sse/utils/setupPolyfill.ts --import ./tests/_setup/isolateDataDir.ts --test --test-force-exit tests/unit/oauth-providers-config.test.ts (27/27 pass)

The patch only removes redundant comment-only lines from the four frozen file-size offenders and does not touch file-size-baseline.json.

I tried both PR merge and direct fast-forward push, but KooshaPari does not have upstream merge/write permission here.

Helper PR: #5200