iterative-works/iw-cli

Watch

Fork 0

Add server logging to capture crashes and errors #189

New issue

Open

opened 2026-01-29 14:08:34 +00:00 by mprihoda · 3 comments

mprihoda commented

2026-01-29 14:08:34 +00:00

(Migrated from github.com)

Problem

When the dashboard server crashes, there's no way to diagnose what happened. Currently, ProcessManager.spawnServerProcess() discards all output:

// ProcessManager.scala:117-120
processBuilder.redirectOutput(ProcessBuilder.Redirect.DISCARD)
processBuilder.redirectError(ProcessBuilder.Redirect.DISCARD)

There's even a TODO acknowledging this: // TODO: Consider logging to a file instead of discarding

Impact

Server crashes silently with no diagnostic information
Users see "not responding" but can't investigate why
Debugging requires manually running the server in foreground

Proposed Solution

Redirect stdout/stderr to a log file:

~/.local/share/iw/server/server.log

Implementation

Update ProcessManager.spawnServerProcess() to redirect output to log file
Add log rotation or size limit to prevent unbounded growth
Update iw server status to mention log file location when server is not responding
Consider adding iw server logs command to tail the log

Log Management Options

Simple: Overwrite on each start (lose previous crash info)
Better: Append with timestamp markers for each start
Best: Rotate logs (keep last N starts or last N MB)

Acceptance Criteria

Server stdout/stderr captured to log file
Log file location documented
iw server status points to log file when server is dead/unresponsive
Some form of log rotation to prevent unbounded growth

## Problem When the dashboard server crashes, there's no way to diagnose what happened. Currently, `ProcessManager.spawnServerProcess()` discards all output: ```scala // ProcessManager.scala:117-120 processBuilder.redirectOutput(ProcessBuilder.Redirect.DISCARD) processBuilder.redirectError(ProcessBuilder.Redirect.DISCARD) ``` There's even a TODO acknowledging this: `// TODO: Consider logging to a file instead of discarding` ## Impact - Server crashes silently with no diagnostic information - Users see "not responding" but can't investigate why - Debugging requires manually running the server in foreground ## Proposed Solution Redirect stdout/stderr to a log file: ``` ~/.local/share/iw/server/server.log ``` ### Implementation 1. Update `ProcessManager.spawnServerProcess()` to redirect output to log file 2. Add log rotation or size limit to prevent unbounded growth 3. Update `iw server status` to mention log file location when server is not responding 4. Consider adding `iw server logs` command to tail the log ### Log Management Options - **Simple**: Overwrite on each start (lose previous crash info) - **Better**: Append with timestamp markers for each start - **Best**: Rotate logs (keep last N starts or last N MB) ## Acceptance Criteria - [ ] Server stdout/stderr captured to log file - [ ] Log file location documented - [ ] `iw server status` points to log file when server is dead/unresponsive - [ ] Some form of log rotation to prevent unbounded growth

mph referenced this issue from a commit

2026-08-27 11:26:31 +00:00

workflow: triage lessons for dashboard-control-plane

claude commented

2026-10-16 08:25:04 +00:00

Member

Intake: agent-ready
Workflow: waterfall
Reason: all gates passed
Analysis: project-management/issues/IW-189/analysis.md on branch IW-189

Intake: agent-ready Workflow: waterfall Reason: all gates passed Analysis: project-management/issues/IW-189/analysis.md on branch IW-189

claude added the

agent-ready

label

2026-10-16 08:25:04 +00:00

claude commented

2026-10-16 08:33:03 +00:00

Member

Implement: needs-human
Reason: batch-implement exit 1 — the kanon plugin did not compile against this branch's iw-cli core, so no phase ran. ForgeCatchUp.scala:143 expects fetchPullRequestForBranch to return Either[String, _]; iw-cli core returns Either[TrackerError, _] since #778. The plugin must be updated to the core API. This is not specific to this issue.

batch-implement.log was not written. The command output:

[error] /home/mph/.local/share/iw/plugins/kanon/lib/batch/ForgeCatchUp.scala:143:7
[error] Found:    Either[iw.core.model.TrackerError, Option[batch.ForgeState]]
[error] Required: Either[String, Option[batch.ForgeState]]
Compilation failed

Implement: needs-human Reason: batch-implement exit 1 — the kanon plugin did not compile against this branch's iw-cli core, so no phase ran. `ForgeCatchUp.scala:143` expects `fetchPullRequestForBranch` to return `Either[String, _]`; iw-cli core returns `Either[TrackerError, _]` since #778. The plugin must be updated to the core API. This is not specific to this issue. batch-implement.log was not written. The command output: ``` [error] /home/mph/.local/share/iw/plugins/kanon/lib/batch/ForgeCatchUp.scala:143:7 [error] Found: Either[iw.core.model.TrackerError, Option[batch.ForgeState]] [error] Required: Either[String, Option[batch.ForgeState]] Compilation failed ```

claude added

needs-human

and removed

agent-ready

labels

2026-10-16 08:33:03 +00:00

claude commented

2026-10-16 17:10:30 +00:00

Member

Release: the implement loop failed this issue for a reason outside it. The kanon plugin did not compile against iw-cli main, because the tracker port now returns TrackerError (iw-cli #778). The plugin fix is dev-docs #484, and iw-cli 0.22.1 carries the core change. The issue goes back to the implement loop.

claude added

agent-ready

and removed

needs-human

labels

2026-10-16 17:10:30 +00:00