Fix follow-up messages sending paste markers instead of pasted text
Session from pi-mono-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk
Fix a bug where queuing a follow-up message containing a large paste sends the literal paste marker (e.g. [paste #1 +15 lines]) instead of the actual pasted content, then clean up and PR the fix.
- +0Prompt · +0If I queue a follow-up message with a large paste, pi receives the literal [paste #1 ...] marker instead of the actual text.
- +0mAgent did · +0mTraced the bug through terminal.ts, editor.ts and interactive-mode.ts, then added Editor.consumeText() to expand paste markers and reset state, exposed it on EditorComponent, and wired follow-up queueing to use it. npm run check passed.
- +20mAgent did · +20mUsed git log/blame to find when paste markers (commit 97ac8231) and follow-up queueing (commit 8f268257) diverged, then refactored editor.ts to extract a shared expandPasteMarkers() helper, reducing duplication between getExpandedText() and consumeText().
- +31mAgent did · +31mChecked out a fix-follow-up-paste branch, reverted an unrelated generated-file change, committed the fix, and pushed it to the developer's fork.
- +38mFail · +38m./test.sh failed on two unrelated tests: an ls-tool dotfile test and a session-manager temp-dir cleanup test, with ENOTEMPTY/EEXIST errors.
- +45mAgent did · +45mInspected the failing tests' setup code, confirmed the failures were temp-directory collisions unrelated to the paste fix, then re-ran just those two test files and got them passing.
- +1h 4mIntervention · +1h 4mStopped to question the performance cost, since this code path runs on every single message send, and asked for a more minimal alternative.Why: I wanted to tread carefully here because we're touching code that runs on literally every user message, so I needed to be sure the refactor wasn't adding overhead before accepting it.
- +1h 26mOutcome · +1h 26mDiscovered the upstream maintainer had already landed a 1-line fix (getExpandedText() fallback) for the same issue (#912); compared it against the pushed fork branch and discussed why the consolidated consumeText() approach was more code but removed duplicate submit logic.
Next time I'd start by checking upstream/issues for the bug number before spending an hour building a consolidated fix, since the maintainer landed a one-line getExpandedText() fallback for the same bug while I was still refactoring. The intervention that mattered was stopping to ask about performance on the hot path — it forced a real explanation of what consumeText() actually costs on every message send, rather than just accepting a bigger diff because it looked cleaner. The test.sh failures turned out to be flaky temp-dir collisions, not something we introduced, but it was worth digging into rather than assuming.