This is a submission for DEV's Summer Bug Smash: Smash Stories.
TL;DR.
I bounded a database read to make my analyzer faster.
I derived the bound carefully, wrote the reasoning into the KDoc, and shipped it behind five passing tests.
The bound was wrong in a way none of those tests could see.
The result: if a lifter deloaded once in the middle of a stall, which is the correct thing for a lifter to do, my app stopped telling them they had plateaued.
No crash.
No error.
No log line.
The feature just quietly stopped being true for the people using the app correctly.
The setup WhyRep analyzes your training rather than just recording it.
The core promise is that it tells you when you have stalled and what to change about it, and that every verdict traces back to a methodology document rather than to something a language model made up.
The architecture decision underneath that promise is that nothing is precomputed.
Verdicts are derived from raw set logs on read, every time, so there is no cached judgement to go stale when the rules change.
Which means every read walked the lifter's entire history for every exercise in the session.
That is fine at ten sessions.
It is not fine at three hundred.
The obvious optimization is to bound the read.
The obvious bound is "it only needs the last two weeks." That was my first wrong answer, and it is worth thirty seconds before I get to the interesting one.
The plateau rules are not measured in calendar time.
They are consecutive-miss counts, and the count varies by lifter tier and by whether the movement is a big or small joint action.
The widest window in the signed methodology is an elite lifter on a small joint action: 14 consecutive sessions without progress.
Train a lateral raise once a week and 14 sessions is over three months of data.
A 14-day cutoff could never have fired a plateau for anyone above beginner tier.
It would not have thrown.
It would have quietly stopped detecting the exact thing the product exists to detect.
The unit was wrong, not the number.
So I threw that out and derived a real bound from the rules table instead.
That is where the actual story starts.
The bound I was proud of Here is the reasoning, and I want you to notice that it is not sloppy.
I wrote this out before writing the code: The widest plateau window is 14 consecutive misses. rebuilds its baseline from a single session.
Nothing accumulates across sessions, so only the miss streak needs historical depth.
The oldest row in a truncated window gets consumed as a fresh baseline and therefore cannot itself count as a miss.
Therefore rows is sufficient.
Exact, even.
I put that reasoning in the KDoc so the next person would not have to rederive it.
I wrote five tests.
All five passed.
I shipped it.
Read that comment again.
It is confident, it is specific, it cites the right constant, and it is wrong.
Why it was wrong does not skip only the first no-verdict session.
It skips every no-verdict session, and it does not reset the streak when it does.
That behaviour is correct and deliberate.
A session that produces no verdict is not evidence of progress and it is not evidence of a miss, so it should neither break the streak nor extend it.
It should be transparent.
But transparent to the streak is not transparent to the row budget.
Every skipped session still consumes a row.
And emits NO_VERDICT on four entirely ordinary paths: a flagged deload a weight change without earned overload a rep-range change a variant change Every one of those eats a row from the budget while contributing nothing to the count.
I had budgeted exactly one spare row.
There is no bound on how many are needed.
Step 3 of my reasoning was true.
Step 4 assumed step 3 was the only case, and I never wrote down that assumption, so I never checked it.
Where the streak went.
The deload consumed a row and contributed no miss, and the two rows that would have completed the streak fell off the end of the window.
What it costs a real lifter I verified it rather