Managed session log file is never written #43

New issue

Closed

opened 2026-05-10 06:59:01 -07:00 by csvance · 2 comments

csvance commented

2026-05-10 06:59:01 -07:00

(Migrated from github.com)

Bug: Managed session log file is never written

Summary

ManagedSession.log_file is constructed and quoted to the user in error messages, but no code path ever writes to it. When a session subprocess crashes, the agent is told "Check log: " and finds nothing there.

Reproduction

Call mcp__kaimon__start_session with a project whose subprocess crashes during boot.
Tool returns Error: Session failed to start — Process died at <ts>\nCheck log: <path>.
The reported path does not exist (or is empty).

Root cause

In src/session_manager.jl:

ManagedSession(project_path; ...) (line ~23) sets log_file = joinpath(log_dir, "$(basename(project_path)).log").
spawn_session! (line ~122) launches the subprocess via Tachikoma.pty_spawn(cmd; rows = 24, cols = 80, env) and stores only the PTY handle in ms.pty. Stdout/stderr go to the PTY master fd; nothing drains them to disk.
Error messages in src/tool_definitions.jl:726,730 quote ms.log_file unconditionally.

Compare with spawn_extension! in src/extension_manager.jl:236-240, which actually opens and redirects to the log file:

log_io = open(ext.log_file, "a")
println(log_io, "\n--- Extension ... starting at ... ---")
flush(log_io)
proc = run(pipeline(cmd; stdout = log_io, stderr = log_io); wait = false)

It also closes log_io in the exit-watcher @async block.

Impact

When a managed session fails to start (bad project, missing dep, instantiate error, version mismatch), the only surfaced error is the generic "Process died at " recorded by _push_session_error!. The actual stack trace and Julia stderr output are lost. This makes debugging session-startup failures effectively impossible without re-running the same command manually outside Kaimon.

src/session_manager.jl — ManagedSession struct (line ~11), spawn_session! (line ~122)
src/tool_definitions.jl:726,730 — error messages that quote ms.log_file
src/extension_manager.jl:230-267 — reference implementation that does write its log

# Bug: Managed session log file is never written ## Summary `ManagedSession.log_file` is constructed and quoted to the user in error messages, but no code path ever writes to it. When a session subprocess crashes, the agent is told "Check log: <path>" and finds nothing there. ## Reproduction 1. Call `mcp__kaimon__start_session` with a project whose subprocess crashes during boot. 2. Tool returns `Error: Session failed to start — Process died at <ts>\nCheck log: <path>`. 3. The reported path does not exist (or is empty). ## Root cause In `src/session_manager.jl`: - `ManagedSession(project_path; ...)` (line ~23) sets `log_file = joinpath(log_dir, "$(basename(project_path)).log")`. - `spawn_session!` (line ~122) launches the subprocess via `Tachikoma.pty_spawn(cmd; rows = 24, cols = 80, env)` and stores only the PTY handle in `ms.pty`. Stdout/stderr go to the PTY master fd; nothing drains them to disk. - Error messages in `src/tool_definitions.jl:726,730` quote `ms.log_file` unconditionally. Compare with `spawn_extension!` in `src/extension_manager.jl:236-240`, which actually opens and redirects to the log file: ```julia log_io = open(ext.log_file, "a") println(log_io, "\n--- Extension ... starting at ... ---") flush(log_io) proc = run(pipeline(cmd; stdout = log_io, stderr = log_io); wait = false) ``` It also closes `log_io` in the exit-watcher `@async` block. ## Impact When a managed session fails to start (bad project, missing dep, instantiate error, version mismatch), the only surfaced error is the generic "Process died at <ts>" recorded by `_push_session_error!`. The actual stack trace and Julia stderr output are lost. This makes debugging session-startup failures effectively impossible without re-running the same command manually outside Kaimon. ## Related files - `src/session_manager.jl` — `ManagedSession` struct (line ~11), `spawn_session!` (line ~122) - `src/tool_definitions.jl:726,730` — error messages that quote `ms.log_file` - `src/extension_manager.jl:230-267` — reference implementation that does write its log

kahliburke commented

2026-06-08 23:07:52 -07:00

(Migrated from github.com)

I'll investigate, thank you for the report and PR. Sorry for the long delay before a response.

👍 1

kahliburke commented

2026-06-16 04:08:05 -07:00

(Migrated from github.com)

Fixed for 2.0 via #44 (@csvance), cherry-picked to 2.0-integration (a0d5198). Managed-session output now tees to the log file through the PTY reader, so a crashed boot's stderr/stacktrace is captured. It also fixes a latent issue — pty.output is a bounded Channel(64) with no consumer for managed sessions, so a verbose or failing boot could fill it and stall the child; the log tee drains it continuously. Verified live: the session log now fills with boot output.

Fixed for 2.0 via #44 (@csvance), cherry-picked to `2.0-integration` (`a0d5198`). Managed-session output now tees to the log file through the PTY reader, so a crashed boot's stderr/stacktrace is captured. It also fixes a latent issue — `pty.output` is a bounded `Channel(64)` with no consumer for managed sessions, so a verbose or failing boot could fill it and stall the child; the log tee drains it continuously. Verified live: the session log now fills with boot output.