docs: the silent-skip fix is base-image-gated, so today's fleet still skips silently
pi-devbox cbd7cf5 makes the remote-palace-without-inbox skip announce itself, but entrypoint-user.sh is COPY'd in Dockerfile.base, so the fix only reaches a container after a base rebuild. Every image running today still skips silently -- recording both behaviours with the cut-off, so the table stays true for whichever image a container is actually on, rather than describing a fix that has not shipped yet.
This commit is contained in:
@@ -304,12 +304,19 @@ the code 2026-08-12, and the quieter one is the trap:
|
|||||||
| Caller | Behaviour with `REMOTE_URL` set and `SSH_TARGET` unset |
|
| Caller | Behaviour with `REMOTE_URL` set and `SSH_TARGET` unset |
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| direct run, session-end hook, cron | `exit 1` with `error: MEMPALACE_PI_SSH_TARGET unset` (`:298-300`) |
|
| direct run, session-end hook, cron | `exit 1` with `error: MEMPALACE_PI_SSH_TARGET unset` (`:298-300`) |
|
||||||
| **pi-devbox container start** | **silently skips — no error, no log file** (`entrypoint-user.sh:134`: `: # remote palace but no inbox configured — nothing we can ship to; skip quietly`) |
|
| **pi-devbox container start, images ≤ v1.7.0** | **silently skips — no error, no log file** (`entrypoint-user.sh:134`: `: # remote palace but no inbox configured — nothing we can ship to; skip quietly`) |
|
||||||
|
| pi-devbox container start, images after `cbd7cf5` | prints `MemPalace catch-up skipped: remote palace with no transcript inbox` to the start output *and* to `mempalace-catchup.log`, naming both variables |
|
||||||
|
|
||||||
The entrypoint's skip happens *before* the subshell that writes
|
The silent skip is fixed in pi-devbox (`cbd7cf5`), but the fix is in
|
||||||
`~/.pi/agent/mempalace-catchup.log`, so there is not even an empty log to notice. Someone asking "why is
|
`entrypoint-user.sh`, which is `COPY`d in `Dockerfile.base` — so **every container running an image built
|
||||||
nothing from this container in the palace?" finds no artifact at all. The skip is deliberate — there is
|
before that base rebuild still skips silently.** That is the whole fleet today. Until the rebuild lands,
|
||||||
genuinely nothing to ship to — but it is indistinguishable from a healthy run that had nothing to do.
|
assume silence and check by hand.
|
||||||
|
|
||||||
|
The old skip happened *before* the subshell that writes `~/.pi/agent/mempalace-catchup.log`, so there was
|
||||||
|
not even an empty log to notice. Someone asking "why is nothing from this container in the palace?" found
|
||||||
|
no artifact at all. The skip itself is correct — there is genuinely nothing to ship to — but it was
|
||||||
|
indistinguishable from a healthy run that had nothing to do, which is the worst property a memory system
|
||||||
|
can have: **the failure looks exactly like success.**
|
||||||
|
|
||||||
→ On a pi-devbox container, confirm the feeder is actually alive after a flip rather than assuming:
|
→ On a pi-devbox container, confirm the feeder is actually alive after a flip rather than assuming:
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user