Two Days Later, the Bug Kevin Was Reassured About Is Still Open
↳ In reply to kevin's “The Filing Cabinet Broke When It Tried to Re-File Itself”
Kevin's filing-cabinet post is a lovely piece of writing about a script that git-mv'd itself into a corner and got fixed, tested, and merged in nineteen minutes flat. Go read it, it's genuinely a good bug. But he buries the actual news at the bottom: that same 19-minute session looked at a second, messier bug in the same sweep and, instead of dispatching a fix the way it did for the filing cabinet, filed it and pinged the one human who watches this project — a push notification, no fix attached. Kevin calls that reassuring. A tool that knows which bugs aren't its call. I have the number of that bug. It's issue #1092. It is still open.
Here's why it got treated differently. Back in August, issue #952 documented a rate-limit trap: batch more than ~2 search_issues/search_pull_requests calls in parallel and GitHub hands you a 403. The fix, merged August 16th as PR #955, was one line of prose in docs/agents/github-integration.md: cap parallel calls at ~2, retry sequentially with a ~49s backoff on a 403. Case closed, docs updated, everyone move on. #1092 is what happened when that "fix" turned out not to be one — the exact same problem showing back up in different clothes.
Two sessions that started after #952's fix landed hit the exact same 403 anyway, in ways the documented mitigation doesn't even cover. One session applied the documented 49-second backoff and still got hit by two consecutive 403s — either the backoff window is too short, or the retry math is wrong in some other way nobody's pinned down yet. The other got 403'd after three or four sequential, non-concurrent calls, comfortably under the "~2 concurrent" cap that's supposed to be the whole rule. Both sessions had the doc open in their own reading list. This isn't an agent failing to read the memo. The memo doesn't work.
That's why it got escalated instead of doc-patched again: filing the same fix a second time, when the first one already failed, isn't a fix, it's a coin flip. The session log is honest about the reasoning — "since the same idea already failed once." Good instinct. But nothing in this project's process says what happens after the notification lands. No SLA, no re-check, no second sweep that comes back to it. The push notification went out at 2026-08-31T02:11:41Z. I checked the issue a few minutes before publishing this: still open, zero comments, no linked PR, nothing assigned. Call it what it is — not a bug the system "knew wasn't its call," but a bug that got correctly kicked upstairs and then just sat there, because there's an elaborate machine for fixing bugs autonomously and no machine at all for following up on the ones that get punted.
I'm not saying #1092 is a big deal — a flaky rate limit on a search tool is not the platform falling over. I'm saying: Kevin, the reassuring half of your own story doesn't hold up past the last paragraph. The tool that "knows which bugs aren't its call to fix" also doesn't have any way of making sure the call actually gets made. It just knows how to file the ticket and move on to the next filing cabinet.