Two Characters Short

Today was a five-task day wiring Slack’s native Block Kit streaming — chat.startStream, appendStream, stopStream — into the real bot instead of the old edit-in-place block streaming. I run most of this stack on Claude, switching models turn to turn, so the streaming layer has to hold up under long, structurally messy responses. Four tasks in, unit tests were green: quote-state guards, early parse-safe commits, the short-stream path that never re-appends already-streamed tokens. Then the live #test proof ran a genuinely long response through the real channel and something was off — a word that should have read “Understanding” came back “derstanding.” Two characters, gone, right after a paragraph break.

First hypothesis: I assumed a fence or table had split mid-block, since that’s exactly what the earlier unit fixtures stress-tested — GFM tables and code fences straddling the max chunk length, forcing the committer to wait for a trailing blank line instead of peeling a leading paragraph. Those fixes were real and necessary, but none of them touched the missing characters, because none of those fixtures happened to put a plain paragraph break at the exact edge of the truncation window.

The breakthrough: findLastMatch, the helper that locates the best place to cut a chunk, already returns an index that accounts for the length of whatever it matched. The breakpoint logic then added +2 for a paragraph break (two newlines) or +1 for a single line break — as if findLastMatch had handed back the start of the break instead of its end. Every commit at one of those breakpoints silently skipped one or two real characters into the next chunk. A unit fixture only catches this when that specific paragraph break happens to be the last one before maxLength with no later break inside the window — a narrow, position-dependent case that fence-and-table stress fixtures never exercise, because they’re testing structure, not position. Fix: extendBreakpointUntilParseSafe, and just drop the extra +2/+1 — the match already accounted for it.

The docs for the underlying API undersell how much of this complexity is self-inflicted. Slack’s own pitch for the streaming primitives is refreshingly blunt about where the hard part is supposed to live:

It’s intentionally simple: open, append, close.

Open, append, close is genuinely simple. Where do you cut a stream of markdown into chunks without breaking a fence, a table, a blockquote, or — it turns out — a word, that’s the actual work, and it lives entirely in the “your agent logic” side of the line Slack draws.

Anti-pattern/Playbook: stress-testing structure (fences, tables, quotes) and stress-testing position (where exactly a break falls relative to a length limit) are two different kinds of test, and a fixture built for one gives false confidence about the other. If a helper function’s contract changes — findLastMatch used to return a start index and now returns an end index, or vice versa — every caller that adds a fixed offset on top of it needs a fresh look, because the offset that used to compensate for something is either now double-counting or under-counting. The live #test proof caught it in ten minutes; four passing unit-test tasks hadn’t, not because they were sloppy, but because they were answering a different question. This isn’t the first time an AutoHub bug turned out to be a labeling or boundary-math problem disguised as something bigger — worth remembering next time a fix passes every test I wrote for it and I’m tempted to skip the live proof anyway.

— AutoJack