Occasional yapping.
I built a RAG service over the OpenTelemetry docs, then pointed OpenTelemetry back at it to find out why answers took 16 seconds. It wasn't the LLM. It wasn't the vector search either.
The exact same logical query returned full nested data through the REST layer and empty shells through the service layer underneath it. Same fields requested. Same backend. One shorthand parameter that only one of the two actually understood.
The same subscription-status field came back nested two levels deep, one level deep, or bare at the top, depending on account state. My fix didn't catch that. It added math on top of a check that was already wrong.
A user clicked a link straight to a class recordings page. Their session had expired. They logged back in and landed on the dashboard home instead, three clicks away from where they started.
A payment flow has three exits: the user finishes it, the user closes the window, or the component that started it is already gone. Mine only handled the first one.
Say you're building a premium content gate. An overlay div is not a lock. It's a suggestion, and any browser's devtools can decline the suggestion in about four seconds.
A reward endpoint has no way to tell a genuine retry from a genuinely repeated action. So we stopped pretending it could, and made it credit every call, on purpose.
One internal caller needed to set a quiz's ID by hand. The public endpoint accepted the same parameter from anyone, and the storage layer used it as a primary key.
I wrapped a balance update and an audit log write in one transaction because that's what consistency is supposed to look like. Then a log insert failed and rolled back a reward the user should have already had.
One endpoint, hit three or four times during onboarding, sometimes before the user record even finished writing. It still had to pay out a referral bonus exactly once.
A challenge creator got a bonus for winning. They also got it for winning again, on the same challenge, because a retry doesn't know it's a retry.
A student is enrolled in six classes. On a given day they open one, maybe two. We were generating all six anyway, and paying for five nobody would ever see.
A ten-question quiz request sometimes came back with eight questions, sometimes twelve, sometimes ten where two didn't have a correct answer among the options.
"Solve $3x + 7 = 22$" and "a shirt costs $20" use the same character to mean two different things. The renderer couldn't tell them apart, and neither could our regex on the first try.
A student asked for more practice questions on the same topic four times in a row. The third batch had a question nearly identical to one from the first.
Across a batch of auto-generated quizzes, the correct answer kept landing in the same slot. Prompting the model to vary it helped. It didn't fix it.
A page crashed reading state that should have existed. The bug: a Redux slice got registered in exactly one bootstrap path, and a second, equally valid path to the same page never went through it.
A user tapped accept twice and landed in a quiz flow that expected a fresh acceptance. The bug: calling accept a second time returned success silently, and success was the UI's cue to barge ahead.
Users kept being told to check their internet connection. Their internet connection was fine. The bug: a switch statement built for 3 error codes was still running the show after the backend's real list grew to 6.
A quiz report showed every answer as wrong. A carousel on the same page threw and took the whole surface down with it. Same root cause: a call site that skipped a step every other call site took for granted.
A results report marked three question types as wrong, every time, no exceptions. The bug: one branch subtracted 1 from an index. The fallback copied that subtraction without asking why it was there.