Refine session stale and stopped states#747
Conversation
|
Deployment failed with the following error: Learn More: https://vercel.com/arul28s-projects?upgradeToPro=build-rate-limit |
|
Warning Review limit reached
Next review available in: 58 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (8)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
arul28
force-pushed
the
ade/discuss-when-why-stale-chip-1a579aac
branch
from
d630268 to
05795a4
Compare
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| if (session.status === "disposed") { | ||
| return { cls: "rounded-full bg-red-400", spinning: false, label: "Stopped" }; | ||
| } | ||
| if (session.status === "failed") { | ||
| return { cls: "rounded-full bg-red-400", spinning: false, label: "Failed" }; | ||
| } |
There was a problem hiding this comment.
For a non-running chat session with status: "disposed" or status: "failed", sessionIndicatorState() returns "running-needs-attention" before these new branches run. The card can then show an amber Ready dot next to Stopped inline text or a Failed capsule, so the same row reports two different states.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/desktop/src/renderer/lib/terminalAttention.ts
Line: 245-250
Comment:
**Chat Status Branches Are Bypassed**
For a non-running chat session with `status: "disposed"` or `status: "failed"`, `sessionIndicatorState()` returns `"running-needs-attention"` before these new branches run. The card can then show an amber `Ready` dot next to `Stopped` inline text or a `Failed` capsule, so the same row reports two different states.
How can I resolve this? If you propose a fix, please make it concise.
| if (args.status === "disposed") { | ||
| return { phase: "stopped", badge: null }; | ||
| } |
There was a problem hiding this comment.
This branch makes disposed sessions with exitCode: 130 or runtimeState: "killed" canonical stopped, but the Live Activity publisher still derives terminal exits from the exit code and has no stopped phase. A user-stopped PTY can show no failed badge in the Work tab while the Live Activity path continues to publish it as failed.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/desktop/src/shared/sessionCanonicalState.ts
Line: 107-109
Comment:
**Stopped Phase Skips Push Mapping**
This branch makes disposed sessions with `exitCode: 130` or `runtimeState: "killed"` canonical `stopped`, but the Live Activity publisher still derives terminal exits from the exit code and has no `stopped` phase. A user-stopped PTY can show no failed badge in the Work tab while the Live Activity path continues to publish it as failed.
How can I resolve this? If you propose a fix, please make it concise.1 participant
Summary
Verification
Greptile Summary
This PR refines how Work sessions report stale and stopped states. The main changes are:
stoppedphase for disposed sessions.Stoppedtext on desktop session cards.Confidence Score: 4/5
The stopped-state paths need fixes before merging.
Non-running chat sessions can show an amber ready dot beside stopped or failed text, and disposed sessions can be canonical stopped locally while the Live Activity exit path still reports failed.
apps/desktop/src/renderer/lib/terminalAttention.ts; apps/desktop/src/shared/sessionCanonicalState.ts
What T-Rex did
Important Files Changed
stoppedphase, moves disposed sessions ahead of failure classification, and increases stale detection to 3 hours.Prompt To Fix All With AI
Reviews (1): Last reviewed commit: "Refine session stale and stopped states" | Re-trigger Greptile