Skip to content

Allow users to set custom codedb timeout via --timeout flag#244

Open
justrach wants to merge 2 commits intomainfrom
feature/243-allow-users-to-set-custom-codedb-timeout
Open

Allow users to set custom codedb timeout via --timeout flag#244
justrach wants to merge 2 commits intomainfrom
feature/243-allow-users-to-set-custom-codedb-timeout

Conversation

@justrach
Copy link
Copy Markdown
Owner

Summary

Adds support for custom idle timeout in the MCP server via the flag.

Changes

  • Changed idle_timeout_ms from const to var in mcp.zig
  • Added setIdleTimeout() function to configure timeout at runtime
  • Parse --timeout=N argument in main.zig for the mcp command
  • Updated help text to document the new flag

Usage

Users can now set a custom idle timeout (in minutes) like:

codedb mcp . --timeout=30

This addresses issue #243 where users needed longer timeouts for debugging sessions.

Closes #243

- Change idle_timeout_ms from const to var in mcp.zig
- Add setIdleTimeout() function to configure timeout
- Parse --timeout=N argument in main.zig for mcp command
- Update help text to document the new flag

Users can now set custom idle timeout like:
  codedb mcp . --timeout=30

Closes #243

Refs #243
@justrach
Copy link
Copy Markdown
Owner Author

Hey @destroyer22719!

This PR implements the custom timeout feature you requested in #243. You can now use:

codedb mcp . --timeout=30

However, I also noticed your comment about the process not actually closing after the timeout. I investigated the idle watchdog code and found a potential issue:

The Problem: The main MCP loop uses blocking I/O (mcpj.readLine() from stdin). When the watchdog detects idle timeout and calls stdin.close(), the blocking read may not always be interrupted properly depending on the OS and how the MCP client manages the pipe.

Current flow:

  1. Watchdog thread detects idle timeout after 10 min (or your custom timeout)
  2. Watchdog calls stdin.close() and sets shutdown = true
  3. But the main thread is blocked in readLine() and doesn't exit until it gets input

This explains why you see the process still running. The timeout is being detected, but the main thread can't exit because it's blocked waiting for input that never comes.

Potential fix: We'd need to either:

  1. Make stdin reads non-blocking with a timeout
  2. Use a select/poll approach in the main loop
  3. Or have the watchdog send a signal to interrupt the read

Should I create a separate issue to track the process exit problem?

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: 58176ae88b

ℹ️ 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 thread src/update.zig
else => return err,
};
if (explicit) |value| {
return .{ .value = value, .source = .env };
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 Strip leading v from explicit update version

resolveTargetVersion returns CODEDB_VERSION verbatim, but the download/checksum URLs later hardcode a v prefix (.../download/v{s}/...). If a user sets CODEDB_VERSION=v0.2.57 (a common tag format), the updater requests vv0.2.57 URLs and fails to fetch the release. Normalizing explicit versions with trimVersionPrefix before storing ResolvedVersion.value avoids this breakage.

Useful? React with 👍 / 👎.

Comment thread src/nuke.zig
}

pub fn commandTargetsBinary(command_line: []const u8, executable_path: []const u8) bool {
if (std.mem.indexOf(u8, command_line, executable_path) != null) return true;
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 Match nuke targets by executable path, not substring

commandTargetsBinary currently returns true whenever executable_path appears anywhere in the command line, which is broader than “this PID is running this binary.” In killOtherCodedbProcesses, that can terminate another codedb process from a different install if one of its arguments happens to contain this path. Restrict the match to the parsed executable path (argv[0], with normalization) to avoid killing unrelated processes.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow users to set custom codedb timeout

1 participant