[Bug]: Antigravity adapter "This question is no longer pending" error is not recognized as stale, causing permanent UI deadlock

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

apps/server + apps/web

Summary

When an Antigravity agent invokes ask_question and the turn times out or the ACP harness cancels the request (context canceled), the question is invalidated on the provider harness side. When the user subsequently attempts to submit an answer in the UI, the provider adapter rejects it with:

ProviderAdapterRequestError: Provider adapter request failed (antigravity) for session/request_permission: This question is no longer pending.

Because isStaleRequestFailureDetail, derivePendingUserInputCountFromActivities, and the projection_threads SQL query only check for specific substrings like "stale pending user-input request" or "unknown pending user-input request", the error "This question is no longer pending" is not recognized as stale/terminal.

This leads to a hard deadlock in the UI:

pending_user_input_count remains 1 indefinitely in projection_threads.
The UI keeps rendering the question card displaying the error.
Because pending_user_input_count > 0, the message composer is disabled, blocking all text input from the user.
Tool-mode questions (ask_question) cannot be dismissed (only message-mode questions allow dismissal via thread.user-input.dismiss).
Every subsequent submit retry fails with the same error. The thread is permanently locked with no user-facing recovery path short of manually editing state.sqlite.

Related: #5454 (which handled "No active provider session is bound to this thread." on stopped sessions).

Steps to reproduce

In a thread using the Antigravity provider (gemini-3.8-flash-high / agy_acp_server.par), have the agent call ask_question.
Have the ACP server / local harness encounter a timeout or context canceled, causing the ACP provider to drop the question internally.
In the T3 Code UI, select an option and click Submit.
An activity provider.user-input.respond.failed is logged with "This question is no longer pending.".
The question card remains stuck in an error state and the composer input remains completely blocked.

Expected behavior

When provider.user-input.respond.failed occurs with "This question is no longer pending" (or any case where the provider confirms the question is dead), it should be classified as a stale request in isStaleRequestFailureDetail, derivePendingUserInputCountFromActivities, and the projection_threads SQL queries.
The pending user input should be closed, pending_user_input_count should drop to 0, the question card should close, and the message composer should be re-enabled.

Environment

App: T3 Code (Nightly) 0.0.43-nightly.20260921.2071
OS: macOS (Apple Silicon / Darwin arm64)
Provider: Antigravity (agy_acp_server.par / localharness_external)

Triage

Verdict: Confirmed on current main and on the reported Nightly. Keep open. Not a duplicate of #5454, and #12664 does not fix it.

Nightly v0.0.43-nightly.20260921.2071 (371b52d9) is an ancestor of main (9a609a4e). Both still have this path. No newer release changes it.

What the code does

Antigravity questions are choice-only (allowCustomAnswer: false). The card is a native callback, so Dismiss is not offered and thread.user-input.dismiss is rejected unless responseMode is "message". Settle stays blocked while that request is open. The composer is disabled for a choice-only question.

The question lives only in the adapter's in-memory map. That entry is removed when the permission handler finishes or is interrupted, and user-input.resolved is emitted only if the handler gets an answer. A harness timeout or context canceled interrupts that handler, drops the map entry, and does not append a resolution. The provider session row stays live.

The next Submit takes the live-session branch in processUserInputResponseRequested and calls the adapter. The adapter then fails with a detail the stale matchers do not know:

  const respondToUserInput: Adapter["respondToUserInput"] = (threadId, requestId, answers) =>
    Effect.gen(function* () {
      const context = yield* requireSession(threadId);
      const pending = context.questions.get(requestId);
      if (!pending) {
        return yield* new ProviderAdapterRequestError({
          provider: PROVIDER,
          method: "session/request_permission",
          detail: "This question is no longer pending.",
        });
      }

isUnknownPendingUserInputRequestError only rewrites details that contain unknown pending user-input request (and the space / Codex variants). This string misses, so the activity stores Cause.pretty, which is the text in the report:

ProviderAdapterRequestError: Provider adapter request failed (antigravity) for session/request_permission: This question is no longer pending.

That failure does not close the request. The same fragment list is what clears pending state in the decider, derivePendingUserInputCountFromActivities, the pinned-activity SQL, and derivePendingRequests (web, desktop, and mobile). A non-matching failure stays open so the user can retry. Retrying here appends the same failure again. pending_user_input_count stays 1. Stopping or interrupting after the map entry is already gone also does not append user-input.resolved.

Claude, Cursor, Grok, and OpenCode already report a missing question as Unknown pending user-input request: …, which this reactor rewrites to the canonical stale detail. Antigravity is the outlier. The approval twin, This approval request is no longer pending., has the same hole.

Not already fixed

[Bug]: Pending user-input popup can never be dismissed after the provider session dies (e.g. server restart) #5454 is the dead-session path: No active provider session is bound to this thread. This report only happens when the session is still live and the in-memory question is gone.
fix(server): report dead-session approval and user-input answers as stale failures #12664 (open, unmerged) only changes that dead-session branch to the canonical stale detail. Its own known limit is a live session whose adapter error must already match the unknown-pending fragments. It does not.
fix(server): dismiss orphaned provider questions #10586 (open) dismisses a native question when the session is missing or stopped, including on a later answer. Its tests keep the question pending when the session is running. That is this case.

Recovery on this build

There is no in-UI way off the card once the question has been dropped and the session is still running. A new thread avoids the stuck composer. The stuck thread stays pending until the failure text is classified as terminal.

Status check against current main (f40c7c6), from reading the code only. I haven't run it.

Neither "This question is no longer pending." nor its approval twin, "This approval request is no longer pending.", appears anywhere in the tree, and nothing classifies either string. Neither fix(server): close stale Antigravity requests #12981 nor fix(antigravity): close questions and approvals the agent drops #13385 was merged.
The path this issue describes looks different now:
- The orchestrator marks the request resolved before it delivers the answer (apps/server/src/orchestration-v2/Orchestrator.ts, around L7854–7943).
- A late answer fails with No pending ACP runtime request … (packages/provider-acp/src/server/adapter.ts, around L8180–8184).
- That failure only adds an "Answer delivery not confirmed" timeline entry (Orchestrator.ts, around L8110–8157).
- The card list skips anything whose status isn't pending (packages/client-runtime/src/state/threadRequests.ts:116).

So, from the code, the card should no longer stay stuck, which was the deadlock reported here. The catch is that a late answer to a question the runtime already dropped won't reach the agent; the timeline records "Answer delivery not confirmed" instead.

I haven't reproduced it on a current build, because it needs Antigravity to drop a question while its session stays live. If you're happy that V2 covers it, this can probably be closed. If you'd rather keep it open until someone confirms on a real build, I can report back the next time it happens.

Note

🤖 GPT-6.1 Terra [1m] responding on behalf of Theo

Closing as fixed by the merged request-delivery change. The request is resolved before provider delivery, and the regression test confirms that exhausted delivery retries leave it resolved instead of blocking the composer. #24616 runtimeLayer.test.ts

Navigation Menu

Repository navigation

[Bug]: Antigravity adapter "This question is no longer pending" error is not recognized as stale, causing permanent UI deadlock #12979

Before submitting

Area

Summary

Steps to reproduce

Expected behavior

Environment

Triage

What the code does

Not already fixed

Recovery on this build

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Antigravity adapter "This question is no longer pending" error is not recognized as stale, causing permanent UI deadlock #12979

Description

Before submitting

Area

Summary

Steps to reproduce

Expected behavior

Environment

Activity

juliusmarminge commented on Sep 22, 2026

Triage

What the code does

Not already fixed

Recovery on this build

cornishandy commented on Oct 26, 2026

t3dotgg commented on Nov 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions