Skip to content

fix: mark stale ongoing sessions as dead after 5min inactivity#100

Merged
matt1398 merged 1 commit intomainfrom
fix/stale-ongoing-detection
Mar 9, 2026
Merged

fix: mark stale ongoing sessions as dead after 5min inactivity#100
matt1398 merged 1 commit intomainfrom
fix/stale-ongoing-detection

Conversation

@matt1398
Copy link
Copy Markdown
Owner

@matt1398 matt1398 commented Mar 9, 2026

Summary

  • Sessions that crash, get killed, or hit usage limits stay marked as "ongoing" because their last JSONL activity is a tool_use/thinking event with no ending event
  • Added an mtime staleness check in ProjectScanner.buildSessionMetadata() — if the session file hasn't been written to in 5+ minutes, isOngoing is overridden to false
  • Uses the already-computed effectiveMtime so no additional I/O is needed

Closes #94

Test plan

  • pnpm typecheck passes
  • All 653 tests pass (42 files)
  • Manual: kill a Claude session mid-task, verify it stops showing as ongoing after ~5 minutes
  • Manual: verify actively running sessions still show the green ongoing indicator

🤖 Generated with Claude Code

Summary by CodeRabbit

Bug Fixes

  • Improved session state detection by marking sessions as inactive when their underlying file hasn't been modified in over 5 minutes, even if session metadata indicates an ongoing state.

Sessions that crash, get killed, or hit usage limits remain marked as
"ongoing" because their last JSONL activity is a tool_use/thinking event
with no ending event. Add an mtime staleness check — if the file hasn't
been written to in 5+ minutes, override isOngoing to false.

Closes #94

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@gemini-code-assist
Copy link
Copy Markdown

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an issue where sessions that crash or are terminated prematurely continue to be displayed as "ongoing" because their activity logs lack a definitive ending event. The solution implements a staleness check that re-evaluates the isOngoing status of a session based on its last modification time, ensuring that sessions inactive for more than five minutes are correctly identified as no longer active.

Highlights

  • Stale Session Handling: Introduced a mechanism to automatically mark sessions as "dead" if they appear ongoing but have not been updated for more than 5 minutes, resolving an issue where crashed or killed sessions remained incorrectly flagged as active.
  • isOngoing Logic Refinement: Modified the isOngoing status calculation within ProjectScanner.buildSessionMetadata() to incorporate a staleness check based on the session file's effectiveMtime, preventing misrepresentation of session activity.
Changelog
  • src/main/services/discovery/ProjectScanner.ts
    • Defined STALE_SESSION_THRESHOLD_MS to set the 5-minute inactivity limit for sessions.
    • Modified the isOngoing property within buildSessionMetadata to override its value to false if the session's effectiveMtime indicates staleness beyond the defined threshold.
Activity
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@coderabbitai coderabbitai bot added the bug Something isn't working label Mar 9, 2026
Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request correctly addresses the issue of stale 'ongoing' sessions by introducing a 5-minute inactivity timeout based on the file's last modification time. The implementation is clean and efficient as it reuses existing file metadata without additional I/O. I have one suggestion to improve code organization regarding the new constant.


// If messages suggest ongoing but the file hasn't been written to in 5+ minutes,
// the session likely crashed/was killed — mark as dead (issue #94)
const STALE_SESSION_THRESHOLD_MS = 5 * 60 * 1000;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

For better code organization and to avoid re-declaring this constant on every function call, consider defining STALE_SESSION_THRESHOLD_MS at a higher scope. A good place would be as a module-level constant at the top of the file, near SEARCH_PROJECT_CACHE_TTL_MS.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4f21f267d3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +760 to +761
const isOngoing =
metadata.isOngoing && Date.now() - effectiveMtime < STALE_SESSION_THRESHOLD_MS;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Avoid timing out legitimately running sessions

This staleness gate can flip an actually active session to isOngoing = false whenever no JSONL write happens for 5 minutes, which is a valid runtime pattern for long tool calls or long assistant steps (for example, a command that blocks without output). In those cases metadata.isOngoing is still true because no ending event has been written yet, so overriding it with Date.now() - effectiveMtime < 5min causes a false “dead” state until another write arrives.

Useful? React with 👍 / 👎.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Mar 9, 2026

📝 Walkthrough

Walkthrough

Implements a stale-session detection heuristic in the project scanner that marks sessions as dead when the underlying file modification time exceeds a 5-minute threshold, even if the session metadata indicates it is ongoing.

Changes

Cohort / File(s) Summary
Stale Session Detection
src/main/services/discovery/ProjectScanner.ts
Adds logic to detect stale sessions by comparing current time against file mtime. When a session appears ongoing but the file hasn't been modified within 5 minutes, the isOngoing field is recalculated and marked as false in the returned Session object, overriding the original metadata value.

Suggested labels

bug

🚥 Pre-merge checks | ✅ 2
✅ Passed checks (2 passed)
Check name Status Explanation
Linked Issues check ✅ Passed The PR implements the stale-session heuristic from issue #94 by adding an mtime staleness check in ProjectScanner.buildSessionMetadata() with a 5-minute threshold, directly addressing the requirement to mark long-inactive sessions as dead.
Out of Scope Changes check ✅ Passed The PR focuses exclusively on the ProjectScanner.ts file with changes limited to the stale-session detection logic in buildSessionMetadata(), remaining fully within the scope of issue #94 requirements.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.


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

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
src/main/services/discovery/ProjectScanner.ts (1)

757-773: LGTM! Solid implementation of stale session detection.

The logic correctly marks sessions as dead when the file hasn't been modified in 5+ minutes while metadata still indicates ongoing activity. Good use of the already-computed effectiveMtime to avoid extra I/O, and the inline comment clearly documents the rationale with a reference to issue #94.

One optional consideration: extract STALE_SESSION_THRESHOLD_MS to module level (alongside SEARCH_PROJECT_CACHE_TTL_MS on line 62) for consistency and easier adjustments/testing.

,

🔧 Optional: Extract constant to module level
 /** How long to reuse the cached project list for search (ms) */
 const SEARCH_PROJECT_CACHE_TTL_MS = 30_000;
+
+/** Threshold after which an "ongoing" session is considered stale/dead (ms) */
+const STALE_SESSION_THRESHOLD_MS = 5 * 60 * 1000;

Then in buildSessionMetadata:

     // If messages suggest ongoing but the file hasn't been written to in 5+ minutes,
     // the session likely crashed/was killed — mark as dead (issue `#94`)
-    const STALE_SESSION_THRESHOLD_MS = 5 * 60 * 1000;
     const isOngoing =
       metadata.isOngoing && Date.now() - effectiveMtime < STALE_SESSION_THRESHOLD_MS;
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/main/services/discovery/ProjectScanner.ts` around lines 757 - 773,
Extract the hardcoded STALE_SESSION_THRESHOLD_MS from inside
buildSessionMetadata to a module-level constant (next to
SEARCH_PROJECT_CACHE_TTL_MS) and replace the local definition with the
module-level one; ensure the constant name remains STALE_SESSION_THRESHOLD_MS
and that buildSessionMetadata (the function computing isOngoing using
effectiveMtime) continues to reference it so behavior is unchanged and
tests/configs can reuse/override the threshold easily.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/main/services/discovery/ProjectScanner.ts`:
- Around line 757-773: Extract the hardcoded STALE_SESSION_THRESHOLD_MS from
inside buildSessionMetadata to a module-level constant (next to
SEARCH_PROJECT_CACHE_TTL_MS) and replace the local definition with the
module-level one; ensure the constant name remains STALE_SESSION_THRESHOLD_MS
and that buildSessionMetadata (the function computing isOngoing using
effectiveMtime) continues to reference it so behavior is unchanged and
tests/configs can reuse/override the threshold easily.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 52dd62cd-cb45-495a-a65f-93315b133933

📥 Commits

Reviewing files that changed from the base of the PR and between 929b31e and 4f21f26.

📒 Files selected for processing (1)
  • src/main/services/discovery/ProjectScanner.ts

@matt1398 matt1398 merged commit f23c581 into main Mar 9, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Several sessions are still marked as ongoing even though they are long dead.

1 participant