a6d1ece15ee6d08fc7e85e0d7644704e771f4908
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
a6d1ece15e |
Remove orchestration_event_push feature flag; rename poller to streamer (#9265)
## Description Removes the `orchestration_event_push` feature flag and the polling fallback in the orchestration event delivery path. SSE-based event push has been on in dogfood and staging long enough that it's now the only path; the dual-mode `OrchestrationEventPoller` is renamed to `OrchestrationEventStreamer` and only opens persistent SSE connections. - Removed `FeatureFlag::OrchestrationEventPush` and the matching Cargo feature. - Renamed `app/src/ai/blocklist/orchestration_event_poller.rs` (and its tests) to `orchestration_event_streamer.rs`. Renamed the public type to `OrchestrationEventStreamer`; renamed the shared event-injection sink `handle_poll_result` → `handle_event_batch`. - Removed polling-only state (`poll_backoff_index`, `poll_in_flight`), methods (`poll_and_inject`, `start_idle_poll_timer`), and constants (`POLL_BACKOFF_STEPS`, `EVENT_POLL_BATCH_LIMIT`). Kept `event_cursor`, `pending_delivery`, and `conversation_statuses` since they are also used by the SSE path. - Removed the now-dead `AIClient::poll_agent_events` trait method and its `ServerApi` implementation in `app/src/server/server_api/ai.rs`. The `OrchestrationV2` flag continues to gate streamer instantiation and watched-run registration; runtime behavior under v2 is unchanged. Pairs with the warp-server PR that drops the flag server-side: https://github.com/warpdotdev/warp-server/pull/10736 — that PR should land first so the polling endpoint stays available for older clients during rollout. ## Testing - `cargo build -p warp` clean. - `cargo clippy -p warp -p warp_features --all-targets -- -D warnings` clean (after `cargo fmt`). - `cargo test -p warp --lib ai::blocklist::orchestration_event_streamer` — all 7 tests pass. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode --- [Plan: Remove orchestration_event_push flag (server + client)](https://staging.warp.dev/drive/notebook/yAlAxMAr4EO65A9LEy40cX) [Conversation](https://staging.warp.dev/conversation/ff5e82cb-bba7-4cbf-ae0b-e51f2c542f4a) --------- Co-authored-by: Oz <oz-agent@warp.dev> |
||
|
|
bc3fffa7e5 |
[APP-4285] Send slash commands as follow-ups with active AI streams (#9243)
## Description Running `/pr-comments` (or any other slash command that targets the currently-selected conversation) while an AI response stream is in-flight crashed in debug builds. `BlocklistAIController::send_request_input` hits its in-flight invariant and fires `safe_assert!(false, ...)` (panics in debug, returns `Err` in release). The user-query path (`send_query`) avoids this because it pre-cancels any active stream on the target conversation with `CancellationReason::FollowUpSubmitted` before calling `send_request_input`. Slash commands bypass that path and dispatch directly via `SlashCommandRequest::send_request`, so the cancel never happens. This PR makes `send_slash_command_request` mirror that cancel-and-resend: if the target conversation has an in-flight stream, cancel it before dispatching. All `SlashCommandRequest` variants are conceptually a fresh user turn (a follow-up), so this matches the semantics users already get from typing a follow-up message. `send_queued_slash_command_request` is unchanged — it's only invoked from `Input::submit_queued_prompt` once the conversation is idle, so no pre-cancel is needed. ## Testing Verified locally. Demo [here](https://www.loom.com/share/a9638ac9a53b48349ce21d03eaba516a)! - Manually reproduced the crash on a dogfood debug build by triggering `/pr-comments` mid-stream; confirmed the panic at the `safe_assert!` in `BlocklistAIController::send_request_input`. - After the fix: same repro cancels the in-flight turn and dispatches `/pr-comments` cleanly. Same behavior verified for `/skills` (InvokeSkill), `/compact` (Summarize), and `/create-environment`. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode ## Changelog Entries for Stable CHANGELOG-BUG-FIX: Fixed an issue where slash commands sent while an agent was still responding were silently dropped. Now, slash commands like `/pr-comments` run as follow-ups, just like typed messages. --- Run: https://staging.warp.dev/conversation/aeecfa2d-1456-440b-9961-c27295d82531 Plan: https://staging.warp.dev/drive/notebook/Ryj2w6xDSqDwNJYhpwwI0Vly |
||
|
|
57e8e3e9be |
Replay agent events on restore (#9251)
## Description Restore orchestration event delivery on the client after a Warp restart so that a parent conversation continues to receive lifecycle events and inbox messages from its children — including terminal events that arrived while Warp was not running. See the full design in `specs/replay-agent-events-on-restore/PRODUCT.md` and `specs/replay-agent-events-on-restore/TECH.md`. This is a re-land of warpdotdev/warp-internal#24999, which was reverted in warpdotdev/warp-internal#25055 due to a CI race. This version fixes the test compilation issue (missing fields in `AmbientAgentTask` struct literal in `conversation_ended_tombstone_view_tests.rs`). ### What - Persists the per-conversation event cursor across restarts. - Adds `last_event_sequence: Option<i64>` to `AgentConversationData` (SQLite) and `AIConversation`. - New `BlocklistAIHistoryModel::update_event_sequence` helper writes the cursor through `write_updated_conversation_state` after each event batch. - Also persists the cursor to the server (fire-and-forget) so driver / cloud restarts can resume without local SQLite state. - Restores `OrchestrationEventPoller.watched_run_ids` and re-establishes event delivery on `BlocklistAIHistoryEvent::RestoredConversations`. - New `on_restored_conversations` handler issues `GET /agent/runs/{run_id}` for each restored parent and uses the response inline `children` and `last_event_sequence` to populate watched run ids and merge the cursor (`max(SQLite, server)`). - Fetch failures retry with exponential backoff (1s, 2s, 5s, 10s capped) keyed off a per-conversation `restore_fetch_failures` counter; reset on success and on conversation removal. - Gated on `OrchestrationV2`. Shared-session viewers and conversations without children are skipped. - `Success` parents resume delivery immediately; `InProgress` parents defer to the existing `on_conversation_status_updated` path. - Restores V1 lifecycle subscriptions on restart by extending the existing `RestoredConversations` handler in `OrchestrationEventService` to re-register `lifecycle_subscription_routes` for restored child conversations whose parents are present locally. ### Why After a Warp restart, parent conversations were silently receiving no further events from children. The `event_cursor` in `OrchestrationEventPoller` was always initialized to 0, so even if delivery had resumed, every event since the start of the conversation would have replayed and produced duplicate messages. V1 lifecycle subscription routes were also not restored, so V1 parents missed child status transitions. ## Testing - Added unit tests in `app/src/ai/blocklist/orchestration_event_poller_tests.rs` covering: cursor merge from server vs SQLite, retry on `get_ambient_agent_task` failure, V2 gating, shared-session-viewer exclusion, cleanup on delete, and `last_event_sequence` round-trip through `AIConversation::new_restored`. - Added unit test coverage in `app/src/ai/blocklist/orchestration_events_tests.rs` for V1 lifecycle re-registration on restore. - Manual verification per `specs/replay-agent-events-on-restore/TECH.md`. ## Server API dependencies - [x] Does this change rely on a [new server API](https://www.notion.so/warpdev/How-to-add-a-new-full-stack-feature-8412cede405a4ec194b32bdd4b951035?pvs=4#04da1e6a493542d68b3e998c7d339640)? - [x] If so, is the use of this API restricted to client channels that rely on the staging server (e.g. WarpDev)? The companion server change adds: - `last_event_sequence` on `Task` (`ai_tasks` column), surfaced inline on `GET /agent/runs/:run_id`. - `PATCH /agent/runs/:run_id/event-sequence` for client cursor writes. - `children` inline on the `GET /agent/runs/:run_id` response. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode Co-Authored-By: Oz <oz-agent@warp.dev> --------- Co-authored-by: Oz <oz-agent@warp.dev> |
||
|
|
0dbd3d567a |
Initial public release of Warp.
Repo-Sync-Origin: warpdotdev/warp-internal@12af1d983b |