ref(chat): Consolidate assistant status handling

[dcramer]

Consolidate Slack assistant status handling behind a single runtime path that owns semantic hint normalization, playful status rendering, periodic refresh, and Slack transport behavior.

This change fixes the long-running status timeout issue by keeping the real phase text in the runtime while refreshing the Slack-visible status before assistant.threads.setStatus expires. It also removes the duplicate tool-start emission path and reuses the same progress reporter for normal turns and OAuth resume so the behavior does not drift.

I considered leaving the recent fix in place and only adding more targeted patches around OAuth resume or tool execution, but that would keep the status pipeline split across multiple layers and transports. Centralizing the status contract makes the Slack timeout behavior, loading_messages payloads, and rendering rules easier to reason about and maintain.

Refs getsentry/junior-prod#22

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
junior-docs	Ready	Preview, Comment	Apr 8, 2026 3:31pm

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Unused test constant never referenced in assertions
  • Removed the unused constant secondPlayfulStatus which was never referenced in any test assertion and would never match actual output given the test configuration.

Or push these changes by commenting:

@cursor push 23bb2b9098

Preview (23bb2b9098)

diff --git a/packages/junior/tests/unit/progress-reporter.test.ts b/packages/junior/tests/unit/progress-reporter.test.ts
--- a/packages/junior/tests/unit/progress-reporter.test.ts
+++ b/packages/junior/tests/unit/progress-reporter.test.ts
@@ -62,7 +62,6 @@
 }
 
 const firstPlayfulStatus = "Thinking task";
-const secondPlayfulStatus = "Reasoning task";
 const secondSearchingStatus = "Searching sources";
 const secondReadingStatus = "Reading source files";
 const secondReviewingStatus = "Reviewing results";

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6cc6c0b. Configure here.}

[sentry]

Bug: A race condition exists where setStatus uses a fire-and-forget promise. This can cause a stale status to be posted after stop() has already cleared the status message.
_{Severity: MEDIUM}

Suggested Fix

Await the postRenderedStatus call within setStatus to ensure status updates are fully processed before the function returns. This will prevent stop() from executing before the status update has been added to the promise queue, eliminating the race condition.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: packages/junior/src/chat/runtime/progress-reporter.ts#L181

Potential issue: The `setStatus` function calls `postRenderedStatus` without awaiting it
(`void postRenderedStatus(...)`). This allows the function to return immediately. If the
agent turn completes and `progress.stop()` is called before the `postRenderedStatus`
promise executes its own internal `postStatus` call, a race condition occurs. The
`stop()` function will clear the status, but the pending `postRenderedStatus` will
subsequently execute and post a stale status message, overwriting the cleared state.
This leaves incorrect visual feedback (e.g., a "Thinking" message) in the Slack thread
after the turn has ended.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[dcramer]

False positive — postStatus serializes all updates through inflightStatusUpdate (line 92-98). Each call chains behind the previous one via await previous. When stop() calls await postStatus(""), it awaits the prior in-flight update before sending the empty status, so ordering is guaranteed. The void just avoids blocking the caller, not the queue.

— Claude Code