Skip to content

Fix duplicate failed_step interventions on mission run failure#357

Closed
cursor[bot] wants to merge 1 commit into
mainfrom
cursor/critical-bug-detection-e93f
Closed

Fix duplicate failed_step interventions on mission run failure#357
cursor[bot] wants to merge 1 commit into
mainfrom
cursor/critical-bug-detection-e93f

Conversation

@cursor
Copy link
Copy Markdown
Contributor

@cursor cursor Bot commented May 25, 2026

Bug and impact

When a mission worker exhausted retries, the orchestrator opened a failed_step intervention. After the run transitioned to failed, the new ensureTerminalFailedRunIntervention path from #355 could open a second intervention for the same step. Operators could resolve one card while the mission stayed blocked on the other.

Root cause

Failed-step identity was inconsistent across creation paths:

  • Worker path stores the orchestrator step id in metadata.stepId
  • Terminal sync path stores the mission step id in metadata.stepId
  • Manual step failure bypassed dedup by calling insertIntervention directly

Dedup only compared metadata.stepId literally, so worker and terminal-sync interventions never matched. The fallback matcher also omitted stepKey when checking mission-only failures.

Fix

  • Add shared failedStepInterventionsMatch() that matches by mission step id, orchestrator step id, or step key (scoped to run when available)
  • Use it in missionService.addIntervention, updateStep failure handling, and ensureTerminalFailedRunIntervention
  • Route plan-board focus through metadata.orchestratorStepId when stepId is a mission id

Validation

  • npx vitest run src/main/services/missions/failedStepInterventionMatching.test.ts
  • npx vitest run src/main/services/orchestrator/aiOrchestratorService.test.ts -t "duplicate worker failed-step|opens terminal failed-step"
Open in Web View Automation 

When a worker exhausts retries and the orchestrator run later fails,
ensureTerminalFailedRunIntervention (#355) could open a second
failed_step intervention for the same step. Worker paths store the
orchestrator step id in metadata.stepId while terminal sync stores the
mission step id, so dedup never matched.

Unify matching across worker, terminal sync, and manual step-failure
paths via failedStepInterventionsMatch, and route updateStep failures
through the same dedup logic.

Co-authored-by: Arul Sharma <arul28@users.noreply.github.com>
@vercel
Copy link
Copy Markdown

vercel Bot commented May 25, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
ade Ignored Ignored Preview May 25, 2026 8:12am

@arul28
Copy link
Copy Markdown
Owner

arul28 commented May 29, 2026

Closing: superseded by #359 (ade/missions removal), which deleted the entire missions/orchestrator subsystem this PR patches (missionService.ts, aiOrchestratorService.ts, missionInterventionRouting.ts). The duplicate failed_step bug is moot and merging would resurrect a deliberately removed feature.

— 2026-05-29 ADE board cleanup

@arul28 arul28 closed this May 29, 2026
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.

2 participants