CHANGELOG: pi -p no longer idles 5 min after answering (mempalace-toolkit 2f0edf5)
Lint / hadolint (push) Successful in 10s
Lint / skill-floor (push) Successful in 13s
Lint / actionlint (push) Successful in 19s
Lint / doc-drift (push) Successful in 19s

The bridge's feed raced its mine against a setTimeout it never cleared, and
print mode waits for an empty event loop. Measured on tor-ms22: exit at 315 s
before the fix, 45 s after (the catch-up feed by design), 3.8 s with
MEMPALACE_FEED=0. check-doc-drift.sh: rc=0, and rc=1 with the SHA removed.
This commit is contained in:
2026-10-13 13:56:50 +02:00
parent 3da7312166
commit 28e324d68f
+19 -1
View File
@@ -18,7 +18,25 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
| Component | Baked in v1.11.0 | Next build | Why | | Component | Baked in v1.11.0 | Next build | Why |
|---|---|---|---| |---|---|---|---|
| pi-extensions | `a88fa99` | **`750b2a8`** (or later: CI resolves `main` at build time) | `mcp-loader.ts` retired; `install.sh` prunes stale links (below) | | pi-extensions | `a88fa99` | **`750b2a8`** (or later: CI resolves `main` at build time) | `mcp-loader.ts` retired; `install.sh` prunes stale links (below) |
| mempalace-toolkit | `975ab92` | **`a30af61`** (or later) | comment/README only: the bridge's `RemoteMcpClient` is now the only copy; `scripts/check-mcp-client-sync.sh` removed. No code change | | mempalace-toolkit | `975ab92` | **`2f0edf5`** (or later) | `pi -p` exits when the feed's mine returns, not 5 min later (below). Also `a30af61`: the bridge's `RemoteMcpClient` is now the only copy, and `scripts/check-mcp-client-sync.sh` is removed (comment/README only) |
### Fixed
- **`pi -p` on a devbox no longer sits idle for five minutes after
answering.** It printed its answer, then held the terminal until a timer
ran out: the feed's 300 s mine deadline (mempalace-toolkit `mempalace.ts`).
The bridge raced its transcript mine against a `setTimeout` it never cleared.
Interactive pi calls `process.exit()` and never showed it, but print mode
(`pi -p`, `--mode json`) waits for an empty event loop. Measured on tor-ms22
(pi 1.1.0): before the fix, `PONG` came at 4 s and exit at 315 s, and that
timer was the only live resource for the last 265 s. After `2f0edf5`, exit
is at 45 s, the moment the session's catch-up feed finishes (prepare 11 s,
mine 31 s). That wait is by design. `MEMPALACE_FEED=0` skips it: 3.8 s.
pi 1.0.0 behaved the same, so it predates v1.11.0. `pi-task` and `fork`
children run `--no-extensions` and were never affected.
`scripts/test-feed-exit.sh` in mempalace-toolkit pins it; the pre-fix source
fails it. Until the next build, scripts that call `pi -p` on a devbox should
keep their `timeout` or set `MEMPALACE_FEED=0`.
### Changed ### Changed