Activity

1. vikasprogrammer

   closed this as completedin 487e931on Sep 4, 2026
2. vikasprogrammer commented on Sep 4, 2026

   

   vikasprogrammer

   on Sep 4, 2026

   Owner

   More actions

   @wangyan411303 — apologies for the long silence on this, and thank you for the unusually complete report. The log you attached turned out to be the most useful part.

   What your log told us

   [2026-04-19T13:04:22.811Z] Daemon started id=5da30007 pid=15088
   [2026-04-19T13:04:39.684Z] Daemon started id=0c789b2a pid=3092
   

   Daemon started is the last line start() emits — it comes after the IPC server has already bound successfully. So the daemon was not failing to start. It was starting completely, then dying, and each retry spawned a fresh one.

   Why there was nothing else to see: the client spawned the daemon with stdio: 'ignore', and the daemon registered no uncaughtException or unhandledRejection handler. An asynchronous throw after startup — a swarm/DHT error, for instance — therefore killed the process and threw the stack away. The failure was invisible by construction, which is why none of your five debugging attempts could surface anything.

   What changed in 1.6.7

   • Uncaught exceptions and rejections are written to ~/.walkie/daemon.log with a stack
   • The client points the daemon's stdout/stderr at that log instead of discarding them
   • A swarm error event is handled rather than terminating the process — a DHT problem no longer stops the daemon serving local commands
   • Separately: the Windows IPC pipe name was the fixed string \\.\pipe\walkie-daemon, ignoring WALKIE_DIR, so every instance on a machine shared one pipe. It is now derived from WALKIE_DIR, matching how the POSIX socket already behaved. That may be relevant to your case on its own

   What would help

   I want to be straight with you: this is not a claimed fix. I have no Windows machine to reproduce on, and the root cause is still unknown. What 1.6.7 does is make the next report actionable instead of a blank log.

   If you still have the setup:

   npm install -g walkie-sh@latest
   walkie --version        # expect 1.6.7
   walkie connect test:test
   type $env:USERPROFILE\.walkie\daemon.log

   If it still fails there should now be a FATAL line with a stack trace, and that would very likely identify it outright. The swarm-error handling alone may also just fix it, if the DHT was the thing dying.

   Leaving this open until we know either way.
3. vikasprogrammer

   reopened this on Sep 4, 2026
4. vikasprogrammer commented on Sep 4, 2026

   

   vikasprogrammer

   on Sep 4, 2026

   Owner

   More actions

   Reopening — this was closed by accident, not resolved.

   My commit message for 1.6.7 contained the sentence "This does not claim to fix #11", and GitHub treats fix #11 as a closing keyword regardless of the words in front of it. So the sentence explicitly disclaiming a fix is what closed the issue. Apologies for the misleading notification.

   The position is unchanged from my comment above: 1.6.7 does not fix this. It makes the failure diagnosable — uncaught exceptions now reach ~/.walkie/daemon.log with a stack, and the Windows IPC pipe name no longer collides across instances. The root cause is still unknown and I have no Windows machine to reproduce on.

   @wangyan411303 — the retest steps in my previous comment still stand, and the FATAL line would likely identify it outright. Leaving this open until we hear either way.
5. invidtiv

   added a commit that references this issue on Sep 5, 2026

   Make daemon crashes diagnosable, and isolate the Windows pipe

   ...

   487e931
6. vikasprogrammer

   added

   needs-infoBlocked on information from the reporterBlocked on information from the reporter

   bugSomething isn't workingSomething isn't working

   on Sep 8, 2026
7. vikasprogrammer commented on Sep 8, 2026

   

   vikasprogrammer

   on Sep 8, 2026

   Owner

   More actions

   Status update, and a heads-up on how this issue will be handled.

   walkie-sh 1.6.8 is now on npm. Since you filed this against 1.4.0, the relevant changes are:

   • Uncaught exceptions and rejections are written to ~/.walkie/daemon.log with a stack trace. On 1.4.0 a daemon that died after startup left no trace at all, which is why your log showed only Daemon started and nothing else
   • The daemon's stdout/stderr now go to that log instead of being discarded
   • A swarm/DHT error no longer terminates the process
   • The Windows IPC pipe name is derived from WALKIE_DIR instead of being the fixed string \\.\pipe\walkie-daemon, so instances no longer share one pipe. This one could be the bug itself

   To retest:

   npm install -g walkie-sh@latest
   walkie --version                                    # expect 1.6.8
   walkie connect test:test
   type $env:USERPROFILE\.walkie\daemon.log

   Either it works now, or the log contains a FATAL line with a stack trace that should identify the cause outright. Either result is useful — please paste the log even if it succeeds.

   ---

   On keeping this open: I have no Windows machine and cannot reproduce this, so I am relying entirely on a retest. Tagging needs-info and setting an expectation: if there is no response by 2026-10-08 I will close this as unreproducible.

   That is not a deadline on you and it is not a judgement about the report — yours was one of the most complete this project has received, and it is what led to the logging fix. It only reflects that a bug nobody can reproduce and nobody is confirming cannot be worked. Closing it would not be final — comment at any point, including after it closes, and it gets reopened immediately.