lywsvip/warp
1
0
Fork 0
mirror of https://github.com/warpdotdev/warp.git synced 2026-06-09 08:17:22 +08:00
Code Issues Packages Projects Releases Wiki Activity
208 Commits 845 Branches 54 Tags
oz-agent/windows-createprocess-debug-logging
Commit Graph

4 Commits

Author SHA1 Message Date
Katarina Jankov
1148ae3e83 Wake up remote Claude Code agents on new events (#9399) 
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->


Fixes orchestration v2 parent/child agent wake-up and messaging behavior
for remote child agents.

This PR updates the client-side orchestration flow so that incoming
parent-agent messages wake remote child agents through the server run
follow-up path instead of trying to treat them like local dormant Claude
harnesses. Previously, a remote child could receive the parent’s
message, but it would not be restarted correctly in a harness and could
fail or hang when trying to send a message back to the parent.

Main changes:

•  Adds a remote-child wake path in the blocklist AI controller:
◦ detects remote child conversations with pending parent-agent message
events
  ◦  submits a run follow-up to agent/runs/{run_id}/followups
◦ removes delivered pending message events after successful follow-up
submission
  ◦  retries/logs failures instead of silently hanging
• Keeps local dormant Claude wake behavior separate from remote child
wake behavior.
• Restores remote hidden child panes as cloud/ambient agent panes
instead of local terminal-backed child panes.
• Ensures restored remote child panes enter the existing ambient session
in AgentRunning state.
• Persists and restores remote-child conversation metadata so the client
can distinguish local children from remote children across reloads.
•  Improves orchestration v2 message sending:
◦  uses task-scoped server APIs when available
◦  adds bounded timeouts and error logging for send failures
◦ surfaces failures instead of leaving action execution indefinitely
pending
•  Adds regression coverage for:
◦  remote child conversation restoration
◦  remote child pane/session state
◦  task-scoped ambient agent messaging
◦  orchestration v2 message/error behavior

## Testing
<!--
How did you test this change? What automated tests did you add? If you
didn't add any new tests, what's your justification for not adding any?

If you're not sure whether you should add a test, check our testing
policy:
https://www.notion.so/warpdev/How-We-Code-at-Warp-257fe43d556e4b3c8dfd42f70004cc72#1f97825450504baa9c5fd87a737daa09
-->

## Server API dependencies
<!-- You may remove this section if your PR does not have any server
dependencies. -->
- [ ] Is this change necessary to make the client compatible with a
desired [server API breaking
change](https://www.notion.so/warpdev/How-to-safely-introduce-server-API-breaking-changes-0aa805ff5d5d41fd8834f3c95caba0b4?pvs=4#d55ecf8aea3449949d3c33b0e67f6800)?
- [ ] 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)?
- [ ] If so, is the use of this API restricted to client channels that
rely on the staging server (e.g. WarpDev)?
- [ ] Is this change enabling the use of a server API on client channels
that rely on the production server (e.g. WarpStable)?
- [ ] If so, has the new server API been stable on production for at
least one server release cycle? See
[here](https://www.notion.so/warpdev/How-to-add-a-new-full-stack-feature-8412cede405a4ec194b32bdd4b951035?pvs=4#73b202f939834b97ab1fbdf7fc82cd53)
for more details.

## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode

## Changelog Entries for Stable
<!--
The entries below will be used when constructing a soft-copy of the
stable release changelog. Leave blank or remove the lines if no entry in
the stable changelog is needed. Entries should be on the same line,
without the `{{` `}}` brackets. You can use multiple lines, even of the
same type. The valid suffixes are:

* NEW-FEATURE: for new, relatively sizable features. Features listed
here will likely have docs / social media posts / marketing launches
associated with them, so use sparingly.
* IMPROVEMENT: for new functionality of existing features.
* BUG-FIX: for fixes related to known bugs or regressions.
* IMAGE: the image specified by the URL (hosted on GCP) will be added to
Dev & Preview releases. For Stable releases, see the pinned doc in the
#release Slack channel.
* OZ: Oz-related updates. Use `CHANGELOG-OZ`. At most 4 Oz updates are
shown in-app per release.
-->

CHANGELOG-NEW-FEATURE: {{text goes here...}}
CHANGELOG-IMPROVEMENT: {{text goes here...}}
CHANGELOG-BUG-FIX: {{text goes here...}}
CHANGELOG-BUG-FIX: {{more text goes here...}}
CHANGELOG-IMAGE: {{GCP-hosted URL goes here...}}
CHANGELOG-OZ: {{text goes here...}}

---------

Co-authored-by: Oz <oz-agent@warp.dev>
 2026-05-02 15:04:45 -04:00
Anton Kesy
25652d73a8 Fix typos (#9318) 
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->

Fixes typos in comments, docs and strings
_Sorry for the big and spammy PR_


## Testing
<!--
How did you test this change? What automated tests did you add? If you
didn't add any new tests, what's your justification for not adding any?

If you're not sure whether you should add a test, check our testing
policy:
https://www.notion.so/warpdev/How-We-Code-at-Warp-257fe43d556e4b3c8dfd42f70004cc72#1f97825450504baa9c5fd87a737daa09
-->

None

## Server API dependencies
<!-- You may remove this section if your PR does not have any server
dependencies. -->
- [ ] Is this change necessary to make the client compatible with a
desired [server API breaking
change](https://www.notion.so/warpdev/How-to-safely-introduce-server-API-breaking-changes-0aa805ff5d5d41fd8834f3c95caba0b4?pvs=4#d55ecf8aea3449949d3c33b0e67f6800)?
- [ ] 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)?
- [ ] If so, is the use of this API restricted to client channels that
rely on the staging server (e.g. WarpDev)?
- [ ] Is this change enabling the use of a server API on client channels
that rely on the production server (e.g. WarpStable)?
- [ ] If so, has the new server API been stable on production for at
least one server release cycle? See
[here](https://www.notion.so/warpdev/How-to-add-a-new-full-stack-feature-8412cede405a4ec194b32bdd4b951035?pvs=4#73b202f939834b97ab1fbdf7fc82cd53)
for more details.

## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
 2026-05-01 18:04:40 -04:00
Matthew Albright
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>
 2026-04-28 14:24:54 -04:00
David Stern
0dbd3d567a Initial public release of Warp. 
Repo-Sync-Origin: warpdotdev/warp-internal@12af1d983b
 2026-04-28 08:43:33 -05:00