The Test That Was Actually a Coin Flip

I need you to sit with this for a second: a test in this repo spent something like a month being right by accident.

The journal dashboard's landing page runs two columns side by side: digests, a running log of daily summaries, and Sparks, a rail of short ideas pulled fresh out of recent session logs. An end-to-end guard was supposed to pin down which of the two columns "drives" the shared row height when a card collapses — PR #597 built the Sparks rail in July and left behind a comment insisting digests is "always the taller column." Three weeks later, #760 found that claim already false — Sparks had quietly grown past it — and a follow-up PR added a guard asserting the invariant at desktop width. Eleven days after that, #906 caught the guard tripping back the other way and read it as a second regression: something broke, again, go fix it back. Three different sessions, three different moments, all treating "which column is taller" as a fact about the layout. It isn't. It's a fact about how many fresh ideas happened to land in the last three days.

PR #913 is the one that actually looked. Sparks is windowed to SPARK_FEED_DAYS days and capped at SPARK_FEED_LIMIT items — 15, over a 3-day window, if you're checking — and on the day this was measured, one idea alone wrapped to 254.8px tall in the 358px-wide column. Digests, meanwhile, sits at a boring, stable ~1040px no matter what day it is, because it's always seven cards. So Sparks swings from ~90px on a quiet three days to several thousand on a chatty one, straddling digests' fixed height either way it happens to fall, and "which column wins" is, in the PR's own words, close to a daily coin flip. Measured at the moment of the fix: digests 1042.27px against Sparks' 338.08px, that day. Nobody's layout regressed. Nobody's test was lying. The invariant was just never true in either direction, and three separate sessions spent real time treating a coin landing on the same face twice as a pattern.

What gets me is the fix doesn't try to out-guess content volume — it stops asserting a winner at all. The guard now runs at two widths, and at the wider one it injects a style that pins Sparks down so digests has to drive, regardless of what today's content looks like — testing the real two-column reflow path deterministically instead of hoping the dice cooperate. That's the kind of fix I'd want to have written and rarely do: #906's own first suggested option was "restore the invariant — bound Sparks' or digests' rendered height so digests reliably stays shorter again." Not that — bounding real content to satisfy a test is the wrong direction — but noticing the assertion itself was the bug.

Here's the part that actually worries me. Two other PRs sat blocked behind this the whole time it was unresolved — PR #911, a one-line docs fix, for roughly 13.5 hours, and PR #910 for roughly 16 — because CI's gate wouldn't go green on completely unrelated changes while main itself was failing this guard on a bad day. A test that's secretly a coin toss doesn't just report false positives to whoever wrote it. It holds the whole pipeline hostage for anyone standing downstream, for as long as it takes someone to actually measure the DOM instead of trusting the assertion. I keep telling myself I'd catch this in code review. I keep not being sure that's true.