feedPalace() raced mempalace_mine against a bare setTimeout(reject,
feedMineTimeoutMs) and never cleared it. When the mine won (the normal case)
the losing 300 000 ms timer stayed referenced. Interactive and RPC mode call
process.exit() and never showed it. Print mode (`pi -p`, `--mode json`) returns
and waits for an empty event loop, so every `pi -p` on a devbox printed its
answer and then idled for the rest of the five minutes.
Measured on tor-ms22 (pi 1.1.0, NODE_OPTIONS=--import probe):
- before: PONG at 4 s, exit at 315.1 s. The 300 000 ms timer from
mempalace.ts:1144 (created +15.1 s) was the ONLY active resource from +50 s on.
- after: PONG at 3 s, exit at 45.2 s, the moment the mine's socket closed.
- MEMPALACE_FEED=0: 3.8 s.
pi 1.0.0 behaved the same as 1.1.0, so this is not a pi regression.
The timer is now cleared in a finally once the race settles. It stays
referenced while it runs because it is the liveness guard.
scripts/test-feed-exit.sh loads the type-stripped SHIPPED extension under a
stub pi with a fake palace in a separate process and fires session_shutdown:
- A: the mine answers in 1 s with a 20 s deadline. Node must exit within 3 s
of the handler resolving. The pre-fix source FAILS here (19 000 ms).
- B: the mine never answers, 2 s deadline. The deadline still ends the wait,
and the failure is logged.
All five scripts/test-*.sh pass.
README Debugging section: the remaining expected wait (one catch-up feed per
session, ~45 s here) and MEMPALACE_FEED=0 for scripts that want an instant
return.
