[Bug Bash 4/17] Active missions not reflected in completed missions count

[joe-rlo]

Environment

hosted-staging (crab shack)

Version / Commit Hash

staging-2026-04-17

QA Test Date

2026-04-17

Feature Area

Missions → status tracking dashboard

Steps to Reproduce

1. Create and run a mission (e.g., bitcoin_price_check)
2. Let the mission execute
3. Open the Missions dashboard
4. Check Active vs Completed sections

Expected Behavior

Completed missions should be moved from "Active" to "Completed" and reflected in the completed count.

Actual Behavior

Missions appear only under "Active" and the "Completed" count remains 0, even after execution completes. Dashboard shows: 6 Total, 6 Active, 0 Paused, 0 Completed, 0 Failed. All missions (bitcoin_price_check, expected-behavior, conversation-insights, skill-extraction, skill-repair, self-improvement) remain in Active status indefinitely. Related to #2536 (mission-project pipeline) but this is specifically about status transition tracking.

Logs / Screenshots

Discovered during Bug Bash 4/17 session. Missions dashboard screenshot shows all 6 missions stuck in Active with 0 Completed.

Pre-submit checklist

• Title is specific (not "fix Google Suite" but "Google Suite install throws invalid_grant on OAuth step")
• Commit hash is filled in
• Steps are numbered and reproducible

[joe-rlo]

Bug Bash 4/20 update: Missions count is still incorrect on staging (v0.25.0) and the problem appears to be getting worse. The count keeps inflating over time — the dashboard now shows a higher total than the actual number of missions created. This suggests the counter is incrementing on each execution cycle rather than reflecting the true mission count. Likely related to the runaway thread issue filed in #2736.

[henrypark133]

We dug through the mission lifecycle and decided not to treat recurring missions as terminal after each run. The core problem here is that is mission-level scheduler state, while success/failure/completion for individual executions belongs at the run level.\n\nThis branch changes the UI/API to surface persisted run history under active missions instead of forcing recurring missions into / after one attempt. Concretely:\n\n- recurring missions remain when they are still eligible to run again\n- completed/failed prior runs are shown in the Missions tab and project drill-in\n- mission detail now includes run-summary counts and a newest-first runs list\n\nSo this addresses the visibility problem that prompted this issue, but it intentionally does not move recurring missions from to or increment the mission-level count for them.\n\nA PR is going up from with that model. Refs #2585.

[henrypark133]

Follow-up correction: my previous comment lost the backticked identifiers because of shell interpolation.

We dug through the mission lifecycle and decided not to treat recurring missions as terminal after each run. The core problem here is that Mission.status is mission-level scheduler state, while success/failure/completion for individual executions belongs at the run level.

This branch changes the UI/API to surface persisted run history under active missions instead of forcing recurring missions into Completed/Failed after one attempt. Concretely:

• recurring missions remain Active when they are still eligible to run again
• completed/failed prior runs are shown in the Missions tab and project drill-in
• mission detail now includes run-summary counts and a newest-first runs list

So this addresses the visibility problem that prompted this issue, but it intentionally does not move recurring missions from Active to Completed or increment the mission-level Completed count for them.

A PR is going up with that model. Refs #2585.