docs(changelog): note the mempalace feed-tick fix this image carries

The recurring "[mempalace ext] feed (tick) failed: mine timed out after 30000ms" message is fixed in mempalace-toolkit (309980b + e68ee20) and this image is what delivers it, since CI resolves MEMPALACE_TOOLKIT_REF to a commit SHA at build time. Worth a changelog entry rather than leaving it implicit in a ref bump: it is the most visible symptom operators on this fleet have been living with, and the entry records that it was a genuine defect (overlapping mines on a single-writer palace) rather than the cosmetic annoyance it was parked as.
2026-09-10 20:58:42 +02:00
parent ff6fd1492a
commit 1c905480e3
1 changed files with 22 additions and 0 deletions
@@ -225,6 +225,28 @@ the one fact that is decided at **build** time and cannot be recovered later.
 Older images degrade cleanly — the field is absent, `jq // empty` yields nothing,
 and the line prints plain `baked` exactly as before.
 **This image also carries a real fix for the recurring
 `[mempalace ext] feed (tick) failed: mine timed out after 30000ms` message** that
 has been appearing in the pi TUI across the fleet since August
 (`mempalace-toolkit` `309980b` + `e68ee20`, picked up because CI resolves
 `MEMPALACE_TOOLKIT_REF` to a commit SHA at build time). It was parked as cosmetic
 on 2026-08-27 and it was not cosmetic: `lastFeedAt` was recorded only after a
 *successful* wait, but the extension's `Promise.race` abandons only the **wait**
 and cannot cancel the mine, so a timeout left the 10-minute debounce clock stale
 — and with `feedInFlight` already cleared, **both** guards stood open and every
 following settled turn started another mine on top of the one still running.
 Overlapping writers on a single-writer palace, each making the next slower and
 the next timeout likelier, which is why the message appeared many times per
 session instead of at most once per debounce window. Simulated over ten minutes
 of settled turns with a 60s mine: **16 mines launched, 15 of them overlapping**
 before; **2 and 0** after. Nothing was ever lost — the transcript is staged
 before the mine and `mine --mode convos` is idempotent — so this was wasted work
 and a misleading error, not data loss. The deadline also rose from 30s to 5
 minutes: the mine is the slowest call the extension makes (30–60s normally) yet
 carried the tightest deadline, 4x tighter than the `prepare` before it and 10x
 tighter than the init handshake. On a healthy fleet the message should now be
 absent; if it appears it is informative — a mine exceeding five minutes.
 ---
 ## v1.8.14 — 2026-09-08