host: a Clear that cannot truncate the leaf says nothing and still reads as cleared #2364

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 0e800c9e3abd4dd5a9d0516ede913626
Branch: dev/1-p526-truncate-silent
Base: da7b1a1
At: 2026-11-04T06:23:12Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

What happens

clear() truncates the log leaf with writeFile(logPath, '', 'utf8'), and the whole write chain ends in .catch(() => {}) (core/src/host/diagnostics.js, live main da7b1a1ae4181a83f4f02331bbbbbce09c842da6, :303-304). So when that write fails, the failure is swallowed with no line anywhere:

• append() in the same file reports the same class of failure: :163-165 prints [ds-bot] diagnostics log not written: <code> once.
• clear() prints nothing. Same file, same fileKind guard, one reports and one does not.

Reachable without root: fileKind() checks the file's kind, not its mode, so a plain leaf with mode 0444 passes the guard. The rotated copy is then removed (.1 is gone — that part is #2358's rule and it works) and the truncate fails with EACCES into the empty catch.

Reproduction (non-root, deterministic)

Home with logs/diagnostics.jsonl holding 28 bytes and logs/diagnostics.jsonl.1 present; chmod 0444 the leaf, leave logs/ writable; call rt.diagnostics.clear() and read the disk after it settles:

leafMode=444  leafBytes=28  leafStillHasLines=true  entriesAfterClear=0  rotatedStillThere=false  stderrLines=0

0644 control: leafBytes=0, rotatedStillThere=false, stderrLines=0.

So on a failing truncate the rotated copy is gone, the leaf still holds every line, nothing is said on stderr, and the page's in-memory list is emptied anyway — the window says Cleared the error log. while the file on disk was not cleared. The same probe against the running instance (a11983c5) reads the same on the leaf, and the old tree 1be6eae5 reads the same, so this is not a #2352 regression.

Shapes that reach it in practice: dsh run under sudo once (the log ends up root-owned), a backup restore that changes ownership, a deliberate chmod, chattr +i, or a read-only mount.

Expected

A Clear that cannot truncate the leaf says so, the way append() already does:

• one stderr line, [ds-bot] diagnostics log not truncated: <code> (same shape as :164: the error code, never the home or the folder), and
• the result reports the leaf as not truncated. #2360's contract already has leaf: 'kept' for "the leaf guard refused it or the write failed"; this issue is the missing stderr half plus the test that pins it.

Scope

• core/src/host/diagnostics.js: give the writeFile its own try inside the chain (like the rm above it), report one line, and do not let it reject the chain.
• core/test/diagnostics.test.js: a 0444 leaf → exactly one stderr line, leaf still holds its lines, entries() empty; a 0644 control → zero stderr lines, leaf empty.
• No change to the truncate itself, to the fileKind guard, to the rotated-copy removal rule, or to #2360's result shape beyond the leaf value it already defines.
• Generated output: touching core/src/host/diagnostics.js re-emits the patch that carries it (0001/0007 today), so generate must be a no-op after committing.

Dedupe (live da7b1a1a + closed issues, checked before filing)

diagnostics truncate → 12 hits, diagnostics silent → 12, diagnostics write failure → 8. The nearest are #2358 (closed: the rotated copy could not be removed and the truncate never ran — different step, fixed), #2345 (closed: .1 left behind — different symptom), #2360 (open: makes the result observable; its acceptance (a)–(d) has no 0444 leaf input), #205 (closed: a general silent-catch discussion), #2302 (closed: a read-only window truncating the shared log). No open issue covers a truncate that fails and says nothing.

Scope addition 2026-11-04: the removal order (P-528)

Found by the Product audit at 868efa73 and reproduced against the real module: clear() removes <leaf>.1 before it truncates. So the very same 0444 leaf loses the rotated copy while the leaf keeps every line — { leaf: 'kept', rotated: 'removed' }, .1 gone from disk, 28 bytes still in the leaf, and the one sentence does not mention the old copy. The old lines are unrecoverable and Download cannot reach them.

This belongs in the same change because it is the same chain in the same function and the same test file:

• truncate first; remove .1 only after the truncate succeeded;
• when the truncate fails, nothing is deleted and rotated stays 'none' — the reason the user can fix (chmod, ownership, mount) is then still on disk for a retry;
• when the rm fails (a directory under that name, a logs/ without its write bit), #2358's line and rotated: 'kept' stay exactly as they are.

Test to add: a 0444 leaf with .1 present → { leaf: 'kept', rotated: 'none' }, the .1 bytes still on disk, no rotated copy line, one not truncated line.

Note on the title: the "still reads as cleared" half is already fixed by #2363 (868efa73) — the window now says The error log was not cleared: the host could not truncate it., measured. What remains red is the "says nothing" half plus this removal order.

Scope addition 2026-11-04 (second): a Clear that did not clear must not empty the readable surface (P-530)

Also from the Product audit at 868efa73, and read out of the same function: clear() sets cleared = Date.now() and fresh = [] before it knows the answer (core/src/host/diagnostics.js:285-286), while entries() filters earlier by time > cleared (:213-214) and both report() (:266-275) and logText() (:278) read only that. So a Clear that did not run keeps the disk untouched but empties what the Feedback page and Download show:

0444 leaf: clear() -> {"leaf":"kept","rotated":"none"}, disk still 2 lines,
           entries() -> 0, logText() -> ""

The page then says The error log was not cleared… and, on the same screen, Recent errors · 0 / No errors recorded.; Download returns No entries. — while every byte is still on disk. The window whose whole job is to hand over the scene hands over an empty one. A symlinked leaf reads the same.

Slice: on leaf: 'kept' the call must be a no-op for the readable surface — do not advance cleared, do not drop fresh; advance and reset only when the truncate actually happened (leaf: 'truncated') or when there was nothing to truncate (leaf: 'absent', and the !toFile early return keeps today's behaviour). One moved block plus a test.

Test: 0444 leaf with entries on disk → clear() answers {leaf:'kept'}, then entries() still lists them and logText() still returns them; the 0644 control still empties both.

This is the same family as the .1 order above: a Clear that failed may not have side effects. Same function, same test file, same PR.

Dedupe for the two additions

Open issues grep No errors recorded, clear entries logText, rotated copy, diagnostics clear read-only → this issue and closed #2360/#2358; no open duplicate.