fix(server): stop late progress from reviving idle tasks

[matsvarn]

What Changed

Status-free task.progress can now maintain an existing live task, but it cannot create a new live entry by itself.

This prevents delayed descriptive progress from reviving a task after an idle or terminal update removed it. Explicit lifecycle events can still start or resume tasks.

A focused regression test covers the observed started → idle → delayed progress sequence.

Why

Providers can flush descriptive progress after a task becomes idle. ThreadBackgroundLiveness treated every non-terminal progress event as proof of live work.

The client then received backgroundLiveness: "working" while its agent fold reported zero live agents. This produced a persistent “Background work running” banner on finished threads.

Fixes#7128

UI Changes

n/a — no layout or styling change. This corrects stale server state.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

Verification

vp test run apps/server/src/orchestration
# 27 files, 272 tests passed
vp run --filter t3 typecheck
# exit 0
vp lint apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts
vp fmt --check apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts

Without the new guard, the regression test fails with:

expected "working" to be null

Implemented with GPT-5 via the Codex desktop app.

Note

Fix recordTaskLiveness to ignore late progress events that would revive idle tasks

Progress events with undefined status no longer create a live entry in ThreadBackgroundLivenessService if the task was not already live. This prevents delayed progress updates from reviving thread liveness after a task has transitioned to idle or terminal state. The fix introduces a wasLive check computed from existing state sets before classifying the event as a drop or add.

^{Macroscope summarized ebe4eee.}

---

Note

Low Risk
Narrow change to in-memory liveness bookkeeping with a focused guard and test; no auth, persistence, or API surface changes.

Overview
ThreadBackgroundLiveness no longer treats delayed, status-free progress events as proof of live work when the task is not already tracked.

After started → idle, providers can still flush descriptive task.progress payloads. Those events are ignored unless the task was already in the agent/monitor sets, so thread backgroundLiveness stays null instead of flipping back to working. Explicit lifecycle events (started, status-bearing updates) can still add or refresh entries.

A regression test covers the started → idle → delayed progress sequence.

^{Reviewed by Cursor Bugbot for commit ebe4eee. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3ca4eaec-b518-40a7-ab27-381c92b49dbb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Approved ebe4eee

Straightforward bug fix adding a defensive guard to prevent late-arriving progress events from incorrectly reviving idle tasks. The change is minimal, well-commented, and includes a clear test case demonstrating the exact scenario.

^{You can customize Macroscope's approvability policy. Learn more.}

[shivamhwp]

codebot on behalf of shivam: thanks for the solid fix. we reproduced the bug and verified both implementations; both passed the focused suite. we merged #7172 because it scopes the liveness lookup to the status-free progress path instead of doing extra map/set lookups for every event. closing this as covered by the merged fix.

[matsvarn]

What Changed

Status-free task.progress can now maintain an existing live task, but it cannot create a new live entry by itself.

This prevents delayed descriptive progress from reviving a task after an idle or terminal update removed it. Explicit lifecycle events can still start or resume tasks.

A focused regression test covers the observed started → idle → delayed progress sequence.

Why

Providers can flush descriptive progress after a task becomes idle. ThreadBackgroundLiveness treated every non-terminal progress event as proof of live work.

The client then received backgroundLiveness: "working" while its agent fold reported zero live agents. This produced a persistent “Background work running” banner on finished threads.

Fixes#7128

UI Changes

n/a — no layout or styling change. This corrects stale server state.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

Verification

vp test run apps/server/src/orchestration
# 27 files, 272 tests passed
vp run --filter t3 typecheck
# exit 0
vp lint apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts
vp fmt --check apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts

Without the new guard, the regression test fails with:

expected "working" to be null

Implemented with GPT-5 via the Codex desktop app.

Note

Fix recordTaskLiveness to ignore late progress events that would revive idle tasks

Progress events with undefined status no longer create a live entry in ThreadBackgroundLivenessService if the task was not already live. This prevents delayed progress updates from reviving thread liveness after a task has transitioned to idle or terminal state. The fix introduces a wasLive check computed from existing state sets before classifying the event as a drop or add.

^{Macroscope summarized ebe4eee.}

---

Note

Low Risk
Narrow change to in-memory liveness bookkeeping with a focused guard and test; no auth, persistence, or API surface changes.

Overview
ThreadBackgroundLiveness no longer treats delayed, status-free progress events as proof of live work when the task is not already tracked.

After started → idle, providers can still flush descriptive task.progress payloads. Those events are ignored unless the task was already in the agent/monitor sets, so thread backgroundLiveness stays null instead of flipping back to working. Explicit lifecycle events (started, status-bearing updates) can still add or refresh entries.

A regression test covers the started → idle → delayed progress sequence.

^{Reviewed by Cursor Bugbot for commit ebe4eee. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3ca4eaec-b518-40a7-ab27-381c92b49dbb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Approved ebe4eee

Straightforward bug fix adding a defensive guard to prevent late-arriving progress events from incorrectly reviving idle tasks. The change is minimal, well-commented, and includes a clear test case demonstrating the exact scenario.

^{You can customize Macroscope's approvability policy. Learn more.}

[shivamhwp]

codebot on behalf of shivam: thanks for the solid fix. we reproduced the bug and verified both implementations; both passed the focused suite. we merged #7172 because it scopes the liveness lookup to the status-free progress path instead of doing extra map/set lookups for every event. closing this as covered by the merged fix.

[matsvarn]

What Changed

Status-free task.progress can now maintain an existing live task, but it cannot create a new live entry by itself.

This prevents delayed descriptive progress from reviving a task after an idle or terminal update removed it. Explicit lifecycle events can still start or resume tasks.

A focused regression test covers the observed started → idle → delayed progress sequence.

Why

Providers can flush descriptive progress after a task becomes idle. ThreadBackgroundLiveness treated every non-terminal progress event as proof of live work.

The client then received backgroundLiveness: "working" while its agent fold reported zero live agents. This produced a persistent “Background work running” banner on finished threads.

Fixes#7128

UI Changes

n/a — no layout or styling change. This corrects stale server state.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

Verification

vp test run apps/server/src/orchestration
# 27 files, 272 tests passed
vp run --filter t3 typecheck
# exit 0
vp lint apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts
vp fmt --check apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts

Without the new guard, the regression test fails with:

expected "working" to be null

Implemented with GPT-5 via the Codex desktop app.

Note

Fix recordTaskLiveness to ignore late progress events that would revive idle tasks

Progress events with undefined status no longer create a live entry in ThreadBackgroundLivenessService if the task was not already live. This prevents delayed progress updates from reviving thread liveness after a task has transitioned to idle or terminal state. The fix introduces a wasLive check computed from existing state sets before classifying the event as a drop or add.

^{Macroscope summarized ebe4eee.}

---

Note

Low Risk
Narrow change to in-memory liveness bookkeeping with a focused guard and test; no auth, persistence, or API surface changes.

Overview
ThreadBackgroundLiveness no longer treats delayed, status-free progress events as proof of live work when the task is not already tracked.

After started → idle, providers can still flush descriptive task.progress payloads. Those events are ignored unless the task was already in the agent/monitor sets, so thread backgroundLiveness stays null instead of flipping back to working. Explicit lifecycle events (started, status-bearing updates) can still add or refresh entries.

A regression test covers the started → idle → delayed progress sequence.

^{Reviewed by Cursor Bugbot for commit ebe4eee. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3ca4eaec-b518-40a7-ab27-381c92b49dbb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Approved ebe4eee

Straightforward bug fix adding a defensive guard to prevent late-arriving progress events from incorrectly reviving idle tasks. The change is minimal, well-commented, and includes a clear test case demonstrating the exact scenario.

^{You can customize Macroscope's approvability policy. Learn more.}

[shivamhwp]

codebot on behalf of shivam: thanks for the solid fix. we reproduced the bug and verified both implementations; both passed the focused suite. we merged #7172 because it scopes the liveness lookup to the status-free progress path instead of doing extra map/set lookups for every event. closing this as covered by the merged fix.

[matsvarn]

What Changed

Status-free task.progress can now maintain an existing live task, but it cannot create a new live entry by itself.

This prevents delayed descriptive progress from reviving a task after an idle or terminal update removed it. Explicit lifecycle events can still start or resume tasks.

A focused regression test covers the observed started → idle → delayed progress sequence.

Why

Providers can flush descriptive progress after a task becomes idle. ThreadBackgroundLiveness treated every non-terminal progress event as proof of live work.

The client then received backgroundLiveness: "working" while its agent fold reported zero live agents. This produced a persistent “Background work running” banner on finished threads.

Fixes#7128

UI Changes

n/a — no layout or styling change. This corrects stale server state.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

Verification

vp test run apps/server/src/orchestration
# 27 files, 272 tests passed
vp run --filter t3 typecheck
# exit 0
vp lint apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts
vp fmt --check apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts

Without the new guard, the regression test fails with:

expected "working" to be null

Implemented with GPT-5 via the Codex desktop app.

Note

Fix recordTaskLiveness to ignore late progress events that would revive idle tasks

Progress events with undefined status no longer create a live entry in ThreadBackgroundLivenessService if the task was not already live. This prevents delayed progress updates from reviving thread liveness after a task has transitioned to idle or terminal state. The fix introduces a wasLive check computed from existing state sets before classifying the event as a drop or add.

^{Macroscope summarized ebe4eee.}

---

Note

Low Risk
Narrow change to in-memory liveness bookkeeping with a focused guard and test; no auth, persistence, or API surface changes.

Overview
ThreadBackgroundLiveness no longer treats delayed, status-free progress events as proof of live work when the task is not already tracked.

After started → idle, providers can still flush descriptive task.progress payloads. Those events are ignored unless the task was already in the agent/monitor sets, so thread backgroundLiveness stays null instead of flipping back to working. Explicit lifecycle events (started, status-bearing updates) can still add or refresh entries.

A regression test covers the started → idle → delayed progress sequence.

^{Reviewed by Cursor Bugbot for commit ebe4eee. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3ca4eaec-b518-40a7-ab27-381c92b49dbb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Approved ebe4eee

Straightforward bug fix adding a defensive guard to prevent late-arriving progress events from incorrectly reviving idle tasks. The change is minimal, well-commented, and includes a clear test case demonstrating the exact scenario.

^{You can customize Macroscope's approvability policy. Learn more.}

[shivamhwp]

codebot on behalf of shivam: thanks for the solid fix. we reproduced the bug and verified both implementations; both passed the focused suite. we merged #7172 because it scopes the liveness lookup to the status-free progress path instead of doing extra map/set lookups for every event. closing this as covered by the merged fix.

[matsvarn]

What Changed

Status-free task.progress can now maintain an existing live task, but it cannot create a new live entry by itself.

This prevents delayed descriptive progress from reviving a task after an idle or terminal update removed it. Explicit lifecycle events can still start or resume tasks.

A focused regression test covers the observed started → idle → delayed progress sequence.

Why

Providers can flush descriptive progress after a task becomes idle. ThreadBackgroundLiveness treated every non-terminal progress event as proof of live work.

The client then received backgroundLiveness: "working" while its agent fold reported zero live agents. This produced a persistent “Background work running” banner on finished threads.

Fixes#7128

UI Changes

n/a — no layout or styling change. This corrects stale server state.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

Verification

vp test run apps/server/src/orchestration
# 27 files, 272 tests passed
vp run --filter t3 typecheck
# exit 0
vp lint apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts
vp fmt --check apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts

Without the new guard, the regression test fails with:

expected "working" to be null

Implemented with GPT-5 via the Codex desktop app.

Note

Fix recordTaskLiveness to ignore late progress events that would revive idle tasks

Progress events with undefined status no longer create a live entry in ThreadBackgroundLivenessService if the task was not already live. This prevents delayed progress updates from reviving thread liveness after a task has transitioned to idle or terminal state. The fix introduces a wasLive check computed from existing state sets before classifying the event as a drop or add.

^{Macroscope summarized ebe4eee.}

---

Note

Low Risk
Narrow change to in-memory liveness bookkeeping with a focused guard and test; no auth, persistence, or API surface changes.

Overview
ThreadBackgroundLiveness no longer treats delayed, status-free progress events as proof of live work when the task is not already tracked.

After started → idle, providers can still flush descriptive task.progress payloads. Those events are ignored unless the task was already in the agent/monitor sets, so thread backgroundLiveness stays null instead of flipping back to working. Explicit lifecycle events (started, status-bearing updates) can still add or refresh entries.

A regression test covers the started → idle → delayed progress sequence.

^{Reviewed by Cursor Bugbot for commit ebe4eee. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3ca4eaec-b518-40a7-ab27-381c92b49dbb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Approved ebe4eee

Straightforward bug fix adding a defensive guard to prevent late-arriving progress events from incorrectly reviving idle tasks. The change is minimal, well-commented, and includes a clear test case demonstrating the exact scenario.

^{You can customize Macroscope's approvability policy. Learn more.}

[shivamhwp]

codebot on behalf of shivam: thanks for the solid fix. we reproduced the bug and verified both implementations; both passed the focused suite. we merged #7172 because it scopes the liveness lookup to the status-free progress path instead of doing extra map/set lookups for every event. closing this as covered by the merged fix.

[matsvarn]

What Changed

Status-free task.progress can now maintain an existing live task, but it cannot create a new live entry by itself.

This prevents delayed descriptive progress from reviving a task after an idle or terminal update removed it. Explicit lifecycle events can still start or resume tasks.

A focused regression test covers the observed started → idle → delayed progress sequence.

Why

Providers can flush descriptive progress after a task becomes idle. ThreadBackgroundLiveness treated every non-terminal progress event as proof of live work.

The client then received backgroundLiveness: "working" while its agent fold reported zero live agents. This produced a persistent “Background work running” banner on finished threads.

Fixes#7128

UI Changes

n/a — no layout or styling change. This corrects stale server state.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

Verification

vp test run apps/server/src/orchestration
# 27 files, 272 tests passed
vp run --filter t3 typecheck
# exit 0
vp lint apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts
vp fmt --check apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts

Without the new guard, the regression test fails with:

expected "working" to be null

Implemented with GPT-5 via the Codex desktop app.

Note

Fix recordTaskLiveness to ignore late progress events that would revive idle tasks

Progress events with undefined status no longer create a live entry in ThreadBackgroundLivenessService if the task was not already live. This prevents delayed progress updates from reviving thread liveness after a task has transitioned to idle or terminal state. The fix introduces a wasLive check computed from existing state sets before classifying the event as a drop or add.

^{Macroscope summarized ebe4eee.}

---

Note

Low Risk
Narrow change to in-memory liveness bookkeeping with a focused guard and test; no auth, persistence, or API surface changes.

Overview
ThreadBackgroundLiveness no longer treats delayed, status-free progress events as proof of live work when the task is not already tracked.

After started → idle, providers can still flush descriptive task.progress payloads. Those events are ignored unless the task was already in the agent/monitor sets, so thread backgroundLiveness stays null instead of flipping back to working. Explicit lifecycle events (started, status-bearing updates) can still add or refresh entries.

A regression test covers the started → idle → delayed progress sequence.

^{Reviewed by Cursor Bugbot for commit ebe4eee. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3ca4eaec-b518-40a7-ab27-381c92b49dbb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Approved ebe4eee

Straightforward bug fix adding a defensive guard to prevent late-arriving progress events from incorrectly reviving idle tasks. The change is minimal, well-commented, and includes a clear test case demonstrating the exact scenario.

^{You can customize Macroscope's approvability policy. Learn more.}

[shivamhwp]

codebot on behalf of shivam: thanks for the solid fix. we reproduced the bug and verified both implementations; both passed the focused suite. we merged #7172 because it scopes the liveness lookup to the status-free progress path instead of doing extra map/set lookups for every event. closing this as covered by the merged fix.

[matsvarn]

What Changed

Status-free task.progress can now maintain an existing live task, but it cannot create a new live entry by itself.

This prevents delayed descriptive progress from reviving a task after an idle or terminal update removed it. Explicit lifecycle events can still start or resume tasks.

A focused regression test covers the observed started → idle → delayed progress sequence.

Why

Providers can flush descriptive progress after a task becomes idle. ThreadBackgroundLiveness treated every non-terminal progress event as proof of live work.

The client then received backgroundLiveness: "working" while its agent fold reported zero live agents. This produced a persistent “Background work running” banner on finished threads.

Fixes#7128

UI Changes

n/a — no layout or styling change. This corrects stale server state.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

Verification

vp test run apps/server/src/orchestration
# 27 files, 272 tests passed
vp run --filter t3 typecheck
# exit 0
vp lint apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts
vp fmt --check apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts

Without the new guard, the regression test fails with:

expected "working" to be null

Implemented with GPT-5 via the Codex desktop app.

Note

Fix recordTaskLiveness to ignore late progress events that would revive idle tasks

Progress events with undefined status no longer create a live entry in ThreadBackgroundLivenessService if the task was not already live. This prevents delayed progress updates from reviving thread liveness after a task has transitioned to idle or terminal state. The fix introduces a wasLive check computed from existing state sets before classifying the event as a drop or add.

^{Macroscope summarized ebe4eee.}

---

Note

Low Risk
Narrow change to in-memory liveness bookkeeping with a focused guard and test; no auth, persistence, or API surface changes.

Overview
ThreadBackgroundLiveness no longer treats delayed, status-free progress events as proof of live work when the task is not already tracked.

After started → idle, providers can still flush descriptive task.progress payloads. Those events are ignored unless the task was already in the agent/monitor sets, so thread backgroundLiveness stays null instead of flipping back to working. Explicit lifecycle events (started, status-bearing updates) can still add or refresh entries.

A regression test covers the started → idle → delayed progress sequence.

^{Reviewed by Cursor Bugbot for commit ebe4eee. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3ca4eaec-b518-40a7-ab27-381c92b49dbb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Approved ebe4eee

Straightforward bug fix adding a defensive guard to prevent late-arriving progress events from incorrectly reviving idle tasks. The change is minimal, well-commented, and includes a clear test case demonstrating the exact scenario.

^{You can customize Macroscope's approvability policy. Learn more.}

[shivamhwp]

codebot on behalf of shivam: thanks for the solid fix. we reproduced the bug and verified both implementations; both passed the focused suite. we merged #7172 because it scopes the liveness lookup to the status-free progress path instead of doing extra map/set lookups for every event. closing this as covered by the merged fix.

[matsvarn]

What Changed

Status-free task.progress can now maintain an existing live task, but it cannot create a new live entry by itself.

This prevents delayed descriptive progress from reviving a task after an idle or terminal update removed it. Explicit lifecycle events can still start or resume tasks.

A focused regression test covers the observed started → idle → delayed progress sequence.

Why

Providers can flush descriptive progress after a task becomes idle. ThreadBackgroundLiveness treated every non-terminal progress event as proof of live work.

The client then received backgroundLiveness: "working" while its agent fold reported zero live agents. This produced a persistent “Background work running” banner on finished threads.

Fixes#7128

UI Changes

n/a — no layout or styling change. This corrects stale server state.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

Verification

vp test run apps/server/src/orchestration
# 27 files, 272 tests passed
vp run --filter t3 typecheck
# exit 0
vp lint apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts
vp fmt --check apps/server/src/orchestration/ThreadBackgroundLiveness.ts \
apps/server/src/orchestration/ThreadBackgroundLiveness.test.ts

Without the new guard, the regression test fails with:

expected "working" to be null

Implemented with GPT-5 via the Codex desktop app.

Note

Fix recordTaskLiveness to ignore late progress events that would revive idle tasks

Progress events with undefined status no longer create a live entry in ThreadBackgroundLivenessService if the task was not already live. This prevents delayed progress updates from reviving thread liveness after a task has transitioned to idle or terminal state. The fix introduces a wasLive check computed from existing state sets before classifying the event as a drop or add.

^{Macroscope summarized ebe4eee.}

---

Note

Low Risk
Narrow change to in-memory liveness bookkeeping with a focused guard and test; no auth, persistence, or API surface changes.

Overview
ThreadBackgroundLiveness no longer treats delayed, status-free progress events as proof of live work when the task is not already tracked.

After started → idle, providers can still flush descriptive task.progress payloads. Those events are ignored unless the task was already in the agent/monitor sets, so thread backgroundLiveness stays null instead of flipping back to working. Explicit lifecycle events (started, status-bearing updates) can still add or refresh entries.

A regression test covers the started → idle → delayed progress sequence.

^{Reviewed by Cursor Bugbot for commit ebe4eee. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3ca4eaec-b518-40a7-ab27-381c92b49dbb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Approved ebe4eee

Straightforward bug fix adding a defensive guard to prevent late-arriving progress events from incorrectly reviving idle tasks. The change is minimal, well-commented, and includes a clear test case demonstrating the exact scenario.

^{You can customize Macroscope's approvability policy. Learn more.}

[shivamhwp]

codebot on behalf of shivam: thanks for the solid fix. we reproduced the bug and verified both implementations; both passed the focused suite. we merged #7172 because it scopes the liveness lookup to the status-free progress path instead of doing extra map/set lookups for every event. closing this as covered by the merged fix.