A season update on a test site took 39 seconds. After the fix it took 2.5.
The fix had shipped nine days earlier. The code change went live, but the database script it depended on was never run.
Copying without removing
A league rollover copies the previous season’s games into the new season. The new code depended on the database script. Without it, rollovers kept copying games and never removed the originals.
The code had shipped and the database script had not run.
Measuring after the script
I applied the missing script. On a test site the update dropped from 39 seconds to 2.5.
Then came the damage. Seventeen leagues were left stuck. Their rollovers were then completed with the script in place, and the count of duplicated games went from 6,195 to 10. The 10 that remain are unrelated old rows.
What “fixed” should have meant
I filed three follow-on tickets out of this. The lesson is narrower anyway. When a code change depends on a schema change, both halves have to be confirmed in production, and “fixed” should mean the second half ran.
For this bug, the check would have been two questions. Did the script run against the production database? Does the behavior it enables show up in a measurement? Here that measurement was 39 seconds against 2.5.
AI Skills
Use this lesson with the AI assistant you already use
A season update on a test site took 39 seconds, and after the fix it took 2.5. The fix had actually shipped nine days earlier, but the database script it depended on was never run.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: A Fix Is Not Done Until Both Its Code and Its Schema Dependency Are Confirmed in Production
SOURCE: dxdev.com/blog/half-shipped-release-breaks-downstream
WHAT HAPPENED: The code change for league rollover went live, but it relied on a database script so that original games would be removed after being copied into the new season. The script was never applied, so rollovers kept copying games and never removed the originals. Once the missing script was applied, the season update on a teammate's test site dropped from 39 seconds to 2.5. Seventeen leagues had been left stuck, and completing their rollovers with the script in place cut duplicated games from 6,195 to 10, where the remaining 10 were unrelated old rows. The whole session took 7 minutes.
THE RULE: When a code change depends on a schema change, both halves must be confirmed in production before the work counts as fixed. Verify that the script ran and that the behavior it enables shows up in a measurement.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. For every code change that depends on a database script, there is a recorded confirmation that the script was run against the production database, not just merged or shipped.
2. A before and after measurement of the behavior the fix targets (such as 39 seconds versus 2.5) is taken in production before the ticket is closed as fixed.
3. The release process blocks or flags a code deploy whose required schema script has no confirmed production run.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
