Skip to content

fix(wework): preserve provider active turn state - #2518

Merged
qdaxb merged 7 commits into
mainfrom
fix/runtime-active-turn-state
Aug 9, 2026
Merged

qdaxb merged 7 commits into
mainfrom
fix/runtime-active-turn-state

Conversation

@qdaxb

@qdaxb qdaxb commented Aug 9, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • derive runtime running state from either the local execution registry or an in-progress provider turn
  • reject normal sends while the provider still has an active turn, while preserving explicit interrupt-and-send
  • recover stale idle UI state by refreshing task state, keeping the user message queued, and retrying it after the active turn completes
  • cover reload recovery and idle restoration in desktop E2E, and document the lifecycle contract in Chinese and English

Verification

  • cargo test --manifest-path executor/Cargo.toml --all-features --lib
  • pnpm --filter wework lint
  • pnpm --filter wework typecheck
  • focused Wework unit suite: 174 tests passed
  • runtime native update contract: 4 tests passed
  • runtime send contract: 33 tests passed
  • desktop Goal E2E including reload during active continuation
  • isolated real Tauri verification: running state and pause action survived reload; completion restored the send action
  • repository pre-push quality checks passed

Summary by CodeRabbit

  • Improvements
    • Task status now accurately remains “running” while work continues, including after app reloads or runtime restarts.
    • Automatic Goal continuation stays active across turns and restores its progress after reload.
    • Follow-up messages sent during an active turn are queued and retried automatically once the turn finishes.
    • “Interrupt and send” now waits for the previous turn to stop before starting a new one.
    • Busy task indicators, stop controls, and composer states are restored more reliably.

@coderabbitai

coderabbitai Bot commented Aug 9, 2026 •

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Review limit reached

@qdaxb, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 5 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 118339fa-d2a7-4cca-8064-90592889d856

📥 Commits

Reviewing files that changed from the base of the PR and between 73b8d4b and d1d682f.

📒 Files selected for processing (13)
  • docs/en/wegent/developer-guide/local-device-architecture.md
  • docs/zh/wegent/developer-guide/local-device-architecture.md
  • executor/src/runtime_work/handler.rs
  • executor/src/runtime_work/handler/collection.rs
  • executor/src/runtime_work/handler/tasks.rs
  • executor/src/runtime_work/response.rs
  • executor/tests/app_runtime_work_send_contract.rs
  • wework/e2e/desktop/task-flow.e2e.mjs
  • wework/src/components/layout/useWorkbenchPaneSession.ts
  • wework/src/features/workbench/WorkbenchProvider.test.tsx
  • wework/src/features/workbench/runtimeTaskLifecycle/RuntimeTaskLifecycleStore.test.ts
  • wework/src/features/workbench/runtimeTaskLifecycle/reducer.ts
  • wework/src/features/workbench/useWorkbenchRuntimeMessaging.ts
📝 Walkthrough

Walkthrough

Runtime running state now includes active Codex turns. Normal follow-up sends reject overlapping turns and preserve input for retry. Wework restores running state across continuation and reload, while interrupt-and-send waits for interruption.

Changes

Runtime provider-state reconciliation

Layer / File(s) Summary
Provider-derived running state
executor/src/runtime_work/handler.rs, executor/src/runtime_work/handler/queries.rs, executor/src/runtime_work/response.rs, executor/src/runtime_work/handler/tests.rs, executor/tests/app_runtime_work_native_update_contract.rs
Runtime tasks report running when local execution or a Codex turn is active. Thread-level status alone does not mark a task as running.
Active-turn send protection
executor/src/runtime_work/handler/tasks.rs, executor/tests/app_runtime_work_send_contract.rs
Normal sends read the Codex thread and reject active turns. Interrupt-and-send uses the shared send path without the normal overlap check.
Blocked-send lifecycle recovery
wework/src/features/workbench/runtimeTaskLifecycle/*, wework/src/features/workbench/useWorkbenchRuntimeMessaging.ts, wework/src/components/layout/useWorkbenchPaneSession.ts, wework/src/features/workbench/WorkbenchProvider.test.tsx
Busy send errors update lifecycle state, refresh runtime work, preserve queued input, and retry it after the provider turn becomes idle.
Continuation and reload validation
wework/e2e/desktop/task-flow.e2e.mjs, docs/en/wegent/developer-guide/local-device-architecture.md, docs/zh/wegent/developer-guide/local-device-architecture.md
Goal continuation remains running across turns and main-window reloads. Documentation describes the updated state and send flows.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Workbench
  participant Executor
  participant Codex
  Workbench->>Executor: send follow-up
  Executor->>Codex: thread/read
  Codex-->>Executor: active turn status
  Executor-->>Workbench: busy rejection
  Workbench->>Workbench: queue message and preserve running state
  Codex-->>Workbench: turn completion
  Workbench->>Executor: retry queued message
  Executor->>Codex: turn/start
Loading

Possibly related PRs

Suggested reviewers: ficohu, micro66

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 45.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely describes the main change: preserving provider active-turn state in Wework.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches 💡 2
📝 Generate docstrings 💡
  • Create stacked PR
  • Commit on current branch
🛠️ Fix failing CI checks 💡
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/runtime-active-turn-state

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@qdaxb
qdaxb marked this pull request as ready for review August 9, 2026 04:46

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@executor/src/runtime_work/handler/tasks.rs`:
- Around line 564-576: Serialize the active-turn check, local task reservation,
and `spawn_turn` invocation in `handler` using a per-task critical section keyed
by the task/thread identifier, so concurrent sends cannot both pass
`codex_thread_has_in_progress_turn` before starting. Keep the existing response
for an already-running task, and add a concurrent-send contract test that
verifies only one turn is started.
- Around line 646-647: Update the interrupt-and-send flow around
send_message_with_active_turn_check to support provider-only active turns
persisted without in-memory cancellation state. Ensure it detects and interrupts
the persisted provider turn before starting the new turn, and add a contract
test seeding such a task with no local execution that verifies turn/interrupt
precedes turn/start.

In `@wework/e2e/desktop/task-flow.e2e.mjs`:
- Around line 8132-8149: After reloadMainWindow in the active Goal continuation
flow, call control.command('waitFor', ...) for a stable expected post-reload UI
element before invoking waitForSnapshot. Keep awaitReadyAfter for reconnection,
and preserve the existing snapshot assertions for the running Goal state.

In `@wework/src/features/workbench/runtimeTaskLifecycle/reducer.ts`:
- Around line 81-87: Update the send_blocked_by_active_turn case in the reducer
to clear activeTurnId when transitioning turnPhase to idle, while preserving the
existing executionPhase and expectedExecutorRunning updates.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 6b744d1a-b631-4dec-bb48-6494330877b1

📥 Commits

Reviewing files that changed from the base of the PR and between a6eb66f and 73b8d4b.

📒 Files selected for processing (17)
  • docs/en/wegent/developer-guide/local-device-architecture.md
  • docs/zh/wegent/developer-guide/local-device-architecture.md
  • executor/src/runtime_work/handler.rs
  • executor/src/runtime_work/handler/queries.rs
  • executor/src/runtime_work/handler/tasks.rs
  • executor/src/runtime_work/handler/tests.rs
  • executor/src/runtime_work/response.rs
  • executor/tests/app_runtime_work_native_update_contract.rs
  • executor/tests/app_runtime_work_send_contract.rs
  • wework/e2e/desktop/task-flow.e2e.mjs
  • wework/src/components/layout/useWorkbenchPaneSession.ts
  • wework/src/features/workbench/WorkbenchProvider.test.tsx
  • wework/src/features/workbench/runtimeTaskLifecycle/RuntimeTaskLifecycleStore.test.ts
  • wework/src/features/workbench/runtimeTaskLifecycle/RuntimeTaskLifecycleStore.ts
  • wework/src/features/workbench/runtimeTaskLifecycle/reducer.ts
  • wework/src/features/workbench/runtimeTaskLifecycle/types.ts
  • wework/src/features/workbench/useWorkbenchRuntimeMessaging.ts

Comment thread wework/e2e/desktop/task-flow.e2e.mjs Resolved
@qdaxb
qdaxb added this pull request to the merge queue Aug 9, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to a conflict with the base branch Aug 9, 2026
qdaxb added 2 commits August 9, 2026 14:13
…rn-state

# Conflicts:
#	wework/src/components/layout/useWorkbenchPaneSession.ts
#	wework/src/features/workbench/useWorkbenchRuntimeMessaging.ts
@qdaxb
qdaxb added this pull request to the merge queue Aug 9, 2026
Merged via the queue into main with commit 90e46b6 Aug 9, 2026
50 checks passed
@qdaxb
qdaxb deleted the fix/runtime-active-turn-state branch August 9, 2026 06:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant