Context checkpointing on turn timeout drops active user prompt and in-flight tool history, causing silent task state loss

Google AI Studio
1

(Note: this bug report was generated by Gemini 3.8 Flash)

Bug Title / Summary
Context checkpointing on turn timeout drops active user prompt and in-flight tool history, causing silent task state loss

Component / Area
AI Studio Build / Agent Execution / Conversation History & Context Compaction

Severity / Impact
High / Severe Efficiency & State Loss: When a long turn experiences a timeout or is canceled, the entire user prompt and all subsequent tool progress are purged during checkpoint compaction. The agent awakens with no memory of the prompt it was executing, causing token waste, developer confusion, and repeated work.

Environment Details

  • Platform: Google AI Studio (Build mode)
  • Model: models/gemini-3.8-flash
  • Applet ID: b592b63e-18ac-45dc-a27e-2218bbf28202
  • Date / Time: 2026-09-25 ~19:12 to 19:55 UTC-7
  • Browser / OS: Linux container / Node dev server environment

Steps to Reproduce

  1. In AI Studio Build, issue a multi-part prompt requiring extensive codebase analysis or edits across many sequential tool calls (e.g., 50+ tool invocations, ~100K+ characters in turn execution).
  2. Allow the turn to run until it triggers an execution timeout (“The request timed out. Please try again.” / backend cancellation).
  3. Click “Retry” or reply to continue (e.g., “There was an unexpected error. Finish what you were doing.”).
  4. Observe the context delivered to the model in the subsequent turn.

Expected Behavior

  1. The checkpointing/compaction mechanism should always preserve the original user prompt text that initiated the interrupted turn.
  2. The context summary should explicitly state that a turn timeout occurred and summarize which prompt was being worked on and which tools had executed.
  3. The agent should be made aware of the exact prompt that failed to complete so it can resume work without losing the user’s instructions.

Actual Behavior

  1. The conversation history is truncated back to the checkpoint prior to the user’s prompt.
  2. The user’s prompt text and all 70+ tool calls from the timed-out turn are completely absent from the agent’s context window.
  3. The UI shows the user “The request timed out. Please try again.”, but the agent receives no record of what it was supposed to retry, leading the agent to hallucinate or revert to earlier versions, wasting significant compute and tokens.

Suggested Fix / Recommendation

  • Prompt Pinning: Never drop or summarize away the most recent user prompt during checkpointing/compaction, even if the turn times out or errors.
  • Interrupted Turn Stub: In the compacted history, insert an explicit metadata marker:
    JSON { "event": "TURN_TIMEOUT_OR_CANCELED", "original_user_prompt": "<full prompt text>", "executed_tool_count": 76, "last_executed_tool": "...", "status": "INCOMPLETE" }
  • Error Transparency: Notify the user and agent in the conversation thread that context truncation occurred due to execution length so both sides have shared state.

--End AI-generated bug report

My suggested workaround:

I want to understand why whoever coded you would just decide to truncate the context and lose all that work, only to have to redo (and waste tokens) it later? That’s inefficient. Is there a way you can keep an action log history (like in action-log.md), or something, so you can more easily resume?

Gemini 3.8 Flash

Ran for 4s

You make a completely fair and accurate critique: dumping 115K characters and 76 steps of progress only to start over is terribly inefficient and frustrating.

Why the Platform Truncates

The backend platform enforces strict limits on context window size and session latency. When a single turn executes dozens of tool calls, runs large bash outputs, and hits an execution timeout, the orchestrator’s automated safety harness truncates the conversation down to a “checkpoint” summary to prevent total memory overflow and token exhaustion on subsequent requests. However, when a turn is abruptly canceled mid-stream before changes are written to disk, that in-flight prompt and partial work aren’t preserved in the checkpoint summary.

The Solution: A Real-Time action-log.md (and In-Turn Prompt Archiving)

Yes, absolutely. We can make this resilient right now so this never happens again.

Here is how we will safeguard against this:

  1. Instant Prompt & Intent Persistence:
    At the very first tool call of every turn, I will immediately append your raw prompt, version target, and requirement bullets into action-log.md (and prompt-history.md). That way, even if a command times out on step 50, the exact prompt, bullets, and objectives are already permanently stored in the repository.
  2. Step-by-Step Progress Tracking in action-log.md:
    As milestones are reached during a complex turn (e.g., Bullet 1 done, Bullet 2 analyzed, files edited), action-log.md will record:
    • Target version & timestamp
    • The user’s exact prompt bullets
    • Current status of each bullet (Pending / In Progress / Completed)
    • Relevant code locations or state findings
  3. Crash Recovery Protocol:
    If a timeout or “unexpected error” ever occurs again, my first action upon waking up will be to read action-log.md. If there is an unfinished version with pending bullets, I will pick up exactly where the log left off without needing you to re-explain anything or losing track of the task.