Fix/title gen nonblocking

[Leoyzen]

Summary

• Root cause: _maybe_generate_title() was await-ed inline in _process_message_locked() before the agent started streaming. A slow or unresponsive title model (e.g. svc/kimi-k2 with cold-start delay) blocked the entire first message response for seconds.
• Fix 1 (message_routes.py): Changed await _maybe_generate_title() to fire-and-forget via state.create_background_task(). Title arrives asynchronously via the existing metadata_generated signal / SessionUpdatedEvent SSE event.
• Fix 2 (storage/manager.py): Added asyncio.wait_for(timeout=15.0) in _generate_title_from_prompt() as a zombie-task safety net. Prevents background title-generation tasks from hanging forever on a stuck model.

Test plan

• Red flag test: _process_message_locked returns in <0.5s even with a 2s title model (previously took 2.0s)
• Red flag test: full E2E path through _generate_title_core mock also returns fast
• Title still appears asynchronously after background generation completes
• on_title_generated callback still fires
• 15-second timeout prevents zombie tasks on stuck title model
• All 14 existing core title generation tests pass (no regressions)

[Leoyzen]

/gemini review

[gemini-code-assist]

Code Review

This pull request improves the robustness of agent interruption and prevents title generation from blocking message processing. Key changes include tracking active run contexts and iteration tasks at the instance level to ensure they are properly cancelled during an interrupt, making title generation a background task with a 15-second timeout, and ensuring assistant messages are correctly finalized with an aborted state upon user cancellation. Feedback identifies a bug where the agent's internal cancelled flag is not reset for new runs, potential race conditions and history pollution when an agent instance is shared across concurrent sessions, and redundant state tracking for stream tasks.

[gemini-code-assist]

The agent's instance-level self._cancelled flag is set to True during interrupt(), but it is never reset to False when a new run_stream starts. This causes is_cancelled() to return True for all subsequent runs on the same agent instance. The test test_subsequent_run_after_interrupt in test_interrupt.py actually manually resets this flag, which highlights the issue. It should be reset here alongside the run_ctx.cancelled flag.

        run_ctx.cancelled = False
        self._cancelled = False
        run_ctx.current_task = asyncio.current_task()

[gemini-code-assist]

Storing run_ctx in the instance variable self._active_run_ctx creates a race condition if the agent instance is shared across concurrent sessions (as seen in the server's ServerState). If session A is streaming and session B starts, _active_run_ctx will point to session B. A subsequent interrupt() call for session A (without an explicit run_ctx) would then incorrectly target and cancel session B. This is particularly relevant given the server's architecture where a single agent instance appears to be shared.

[gemini-code-assist]

The instance variable self._iteration_task is subject to the same race condition as _active_run_ctx. In a multi-session environment with a shared agent, calling interrupt for one session could inadvertently cancel the LLM iteration task of another session if that session was the most recent one to start. This state should be managed in a way that is isolated per run or session.

[gemini-code-assist]

Adding the aborted message to agent.conversation while the agent instance is shared across sessions can lead to history pollution. If session A is aborted, its partial response is added to the shared conversation object, which might then be visible to session B if it's running concurrently or if the agent state isn't reloaded. While this fixes history for the current session, it highlights the risks of the shared agent architecture.

[gemini-code-assist]

Code Review

This pull request addresses bugs in agent interruption and session title generation by introducing tracking for active run contexts and implementing timeouts for title generation. It also ensures that assistant messages are correctly finalized and persisted when a user cancels a request. The code review feedback highlights critical concurrency issues: storing run contexts and iteration tasks as instance variables on the agent is unsafe for concurrent use, as it leads to race conditions and potential history contamination between sessions. Additionally, a duplicate fixture was identified in the test files.

[gemini-code-assist]

Storing run_ctx and the stream task as instance variables (self._active_run_ctx, self._current_stream_task) is not safe for concurrent run_stream calls on the same agent instance. A subsequent call will overwrite these references, and the finally block of the first call to complete will clear them (lines 701-702). This creates a race condition where active runs can become untracked and un-interruptible if the agent is used concurrently (e.g., in a multi-session server environment).

[gemini-code-assist]

Similar to the issue in BaseAgent, storing iteration_task as an instance variable (self._iteration_task) is unsafe for concurrent runs. If multiple streams are active, they will overwrite this reference, leading to race conditions in tracking and cancellation.

[gemini-code-assist]

The _interrupt method cancels self._iteration_task unconditionally. If multiple runs are active on the same agent instance, this could interrupt an iteration task belonging to a different session than the one intended. This task should be tracked per run_ctx or task to ensure correct scoped cancellation.

[gemini-code-assist]

Adding the aborted message to agent.conversation while the agent instance is shared across sessions can lead to history contamination. If another session has called load_session on the same agent instance before this line executes, the aborted message will be appended to the wrong session's history. This highlights a broader issue with sharing a stateful agent instance across concurrent sessions in the server.