Flow
What goes in the cache
1Found
Keep it for a few minutes, keyed by customer and error
2Confirmed none
Keep it for a shorter time, since new work can show up
3Could not tell
Never keep it; show the reason, like a missing permission
4Tracker outage
A short backoff, kept apart from the answer cache
One bad reply from my error tracker can make my own tool decide a crash has nothing behind it. Then it holds on to that answer for a few minutes and gives it to everyone who asks.
The tool links errors in production to the AI coding sessions that wrote the code. All of this comes from reading my own diff. I didn't watch it fail, and I haven't checked how often it does.
Three calls to the tracker
When an error comes in, the tool asks the tracker for the latest event. It reads the release tag and the files in the stack trace. It asks for the commits in that release and the files they changed. It keeps the commits that touched the stack-trace files, finds their branches, and looks up the sessions on those branches. Then it ranks them. Three of those steps go out to the tracker, and any of them can have a bad second.
Every failure became "nothing"
The first step was already soft. If it couldn't get the event, it gave back null. Then I did a cleanup pass and made the rest soft too. Now not found, not allowed, and server error all come back as null. Errors on the commit and file steps, which used to stop the lookup, now turn into empty lists. On the commit and file steps, the log lines that said which permission was missing got commented out.
Some of that helped. A release with no tag is a real case, and I'd guess I wanted the error page to always show something. But now a failure looks just like a clean "nothing found."
Then the cache kept it
The same pass added a cache that keeps results in memory for a few minutes. It stores the null too. So one bad second at the tracker puts the null in the cache. For the next few minutes, everyone gets "nothing." The tool does not ask again. A failed commit fetch does the same thing one step later and gets cached as "release found, no sessions." Each server process has its own cache, so two people might see two answers for one error.
What I want is a result with three kinds: found, confirmed none, and unknown with a reason. The first two get cached. The third never does.
if (result.kind !== "unknown") cache.put(key, result);
The reason goes on the page, so a permission problem says which permission. Going easy on the tracker during an outage would be a short backoff, kept out of the answer cache. I haven't built this yet.
Wider search, loose score
The pass also made the search wider. One hit on a commit now pulls in the other sessions on that commit's branch, and the cap on how many results come back is gone. That helps after a squash merge. On a long branch, it can flood the list.
The score is just a few added points: on the branch, busy, small release. The page shows it with a percent sign and a confidence-sounding label, but nothing in it checks whether a session touched the file that broke. It's an order, not a chance. I had a big test file for a smarter scorer, one that did look at files. Around the same time, I deleted it as unused, and kept the score that doesn't.