Adley Rutschman still showed as an Oriole five days after Baltimore traded him to Boston. Chasing that one symptom turned into three separate bugs, each one hiding perfectly behind the last. None of them threw. None logged an error. Every single one printed a success message while doing nothing, or the wrong thing, which is a much worse failure mode than just crashing, because a crash at least has the decency to tell you something’s wrong.

The state all three bugs conspired for a week straight to prevent.

First theory was stale cache. Ran the project’s clear-cache script, expected a clean slate, got the same stale data back. Ran it again. ✓ cleared, it said, cheerfully, both times.

1

const CACHE_NAMESPACE = (process.env.CACHE_NAMESPACE || process.env.NODE_ENV || 'dev').trim();

The server runs NODE_ENV=development, writes keys under development:*. The CLI script, run from a plain shell with no env var set, resolves to dev:, deletes zero keys under a namespace that doesn’t exist, and reports success anyway, because delPattern returned void and a zero-match delete looked identical to a real one. Found it by going around the tool entirely, redis-cli EXISTS before and after a “successful” flush, keys still sitting right there. Made delPattern return the actual count deleted from here on, ⚠️ 0 entries cleared reads nothing like ✓ cleared, and this had apparently been the standing, wrong explanation for a whole class of “why didn’t my fix take effect” reports on this project. The fix everyone reached for first had never once worked.

With caching ruled out, the database itself said Baltimore. A trade sync had correctly written Boston days earlier, so something was writing it back, and that something turned out to be a stats importer, a job that pulls a player’s current-season splits and, as a side effect nobody asked for, decided it also owned his team assignment:

1
2
3
4

// Update player's team if this is the most recent MLB team ...
if (player && teamId && teamName && season === CURRENT_SEASON && isMLBTeamId(teamId)) {
  await prisma.player.update({ where: { id: playerId }, data: { teamId, teamName } });
}

The comment says “most recent.” There’s no recency check anywhere in the block, just whatever split MLB’s API hands back next. Rutschman had two Baltimore rows for 2026 and zero for Boston (straight to the injured list, no game played yet), so every re-sync, including one triggered by someone just viewing his page, propped Baltimore back up like it never left.

Weekend at Bernie’s, but for a teamId column. Made the write fill-only, populate a missing team, never overwrite an existing one, and repaired the 51 other players this exact path had quietly reverted.

A third bug, and I promise this is the last of them, was feeding the same symptom, found a couple days earlier in the same chase: fix-milb-teams saw Rutschman parked on a non-MLB affiliate, assumed that meant broken, and “corrected” it by picking whichever MLB club he’d played the most games for historically, which for someone traded five days ago is always the old team. MLB’s API does hand back the real answer directly as currentTeam.parentOrgId, but the Zod schema for that payload never declared the field, and Zod drops unknown keys by default, so the correct value arrived and got silently thrown away before any code of mine ever saw it. My first draft of this fix read parentOrgId, got undefined, and would’ve quietly kept the broken logic while looking fixed, caught only by checking the parsed output against the raw response instead of trusting that adding a schema field was enough on its own (it is never enough on its own, and I know that, and I still nearly shipped it anyway).

Fifty-two players had a genuinely wrong team after that repair. Two hundred seventy-six flagged by the detection query were false positives, guys like Verlander and Scherzer whose team correctly differs from an old trade because they’d moved again on their own since. The script checks with MLB before touching anyone, so only the real 52 changed. Three bugs, one Oriole who was actually a Red Sox the whole time, and a week where every fix I tried made the next bug look like a completely different problem.