From 8c66042e4232979a122448bc7290fca12db5d0ad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Sun, 16 Aug 2026 03:47:47 +0000 Subject: [PATCH] todo: background job logs appeared inside an open file in the editor MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reported on the production host, as a member, with a `bun dev` job streaming: the runner's output rendered into the buffer of a file open in the code editor. The file on disk was intact and nothing was saved, so it is a display-layer mixing rather than a write path. Not reproduced and not diagnosed — logged with the two places the streams can meet (`CodeSurface` is shared between the task panel and the editor; the editor keys by path while panel stores key by panelId through useGlobal/usePanelMemory) and a first move that distinguishes them: whether the buffer is polluted or only the render is, which Cmd+S and a tab reopen answer immediately. Recorded rather than guessed at further. An editor that can show content the file does not contain is a correctness problem even when it never writes, because the instinct on seeing it is to save. Co-Authored-By: Claude Opus 5 --- TODO.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/TODO.md b/TODO.md index 7d0ff3da..88de76c6 100644 --- a/TODO.md +++ b/TODO.md @@ -324,6 +324,33 @@ pane belonging to the folder you left; and the breadcrumb opted out of that last ## Known bugs +- [ ] **Background job logs appeared INSIDE an open file in the code editor.** Reported 2026-08-16 by the + owner, on the production host, running as a member with a `bun dev` background job streaming. The + editor had a file open; the runner's log output was rendered into that file's buffer. **It was never + saved** — the file on disk was intact, and the editor was not marked dirty as far as the report goes. + So this is a DISPLAY-layer mixing, not a write path: the bytes reached a buffer that only exists in + the browser. + + Not reproduced, not diagnosed, and deliberately not guessed at further than this. What is worth + recording is where the two streams could meet, because both were added in the same week and they are + the only two things writing text into a panel: + + - `useTaskDetail` polls `GET /chat/tasks/:id` every 2s while a job runs and returns `{kind:'log', text}`. + `CodeSurface` renders it — and `CodeSurface` is shared with the editor's own surfaces. + - The editor keys open files by PATH (`useEditorState`), while the task panel keys by TASK ID, and + several panel-scoped stores in between are keyed by `panelId` through `useGlobal` / + `usePanelMemory`. A key collision between those namespaces would produce exactly this: one panel's + text arriving in another's buffer, with no server involvement and nothing persisted. + + First moves, in order: reproduce with a job whose output is distinctive (`seq 1 100000`), then check + whether the editor's content state or only its RENDER is affected — `Cmd+S` at that moment answers it, + as does closing and reopening the tab. If the buffer really is clean and only the view is wrong, the + suspect is a shared component instance; if the buffer is polluted, it is a key collision. + + Worth noting because it is the reason to look at all: an editor that can show content the file does + not contain is a correctness problem even when it never writes — the next person's instinct will be to + save the file to "fix" it. + - [ ] **`bootstrap.ts` runs `npm install -g` for Pi on every boot.** `findPiPackageDir` checks stale paths and an outdated package name, so `installPi` always fires and floods the logs with `EEXIST` noise. Should detect `@earendil-works/pi-coding-agent` at the real npm prefix.