A customer wrote in about a save that half-worked. He had added a helper to manage part of a shared scheduling tool for him. The helper tried to save some details and got an error. Some of what he’d entered stuck anyway, some of it didn’t, and he ended up filling in the rest by hand. It read like a permissions problem: a new helper account and a partial failure, which is a familiar shape.
Our own records showed nothing
The first thing we checked was our internal error records for that failure window. There was nothing. No trace of the save attempt arriving and failing. In a support investigation an empty record is usually bad news, because the easiest source of truth has nothing to say.
We didn’t stop there. We reproduced the failure using the helper account itself, through a staff tool that lets support see exactly what a specific customer sees. The error came up on cue, screenshot and all. The records for that window were still empty. That emptiness pointed at the answer once we stopped treating it as a hole in the evidence and started treating it as a fact about what had happened.
Three tabs, two of them wired up
The save screen could be reached from three places in the tool, three tabs showing different views of the same schedule. The save logic only recognized two of them. From the third tab it hit a dead end, showed a generic “something went wrong” message, and stopped without sending anything out at all.
That explained everything at once. The records were empty because there was nothing to record. No request ever left that screen, so there was nothing to fail on our end. It also explained the partial save that looked like a permissions problem. Edits made from the two working tabs went through fine. Edits made from the third tab hit the dead end every time, for anyone. We checked directly, and the account owner got the identical failure from that same tab.
The fix
We connected the third tab’s save action to the same working path the other two already used. We did not patch the dead end to fail a little more gracefully. Then we checked live, on the exact account and the exact save that had failed before, and it went through cleanly. The data that came back matched a snapshot taken right before the fix, so nothing had changed except that the request now actually fired.
What the silence meant
When a customer reports a failure that leaves no trace anywhere in your own systems, it is tempting to doubt the report or assume your recordkeeping swallowed something. Neither was true here. Our records were fine. They correctly said nothing had happened on our end, because nothing had. A failure that happens before a request is ever sent leaves silence, and that silence told us to stop looking at what happened after the request arrived and start looking at what kept it from being made at all.
AI Skills
Use this lesson with the AI assistant you already use
A customer's save attempt failed with a visible error, but nothing in our internal records showed it happening at all. That absence turned out to be the whole answer, once it was read as a clue instead of a gap.
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 missing record is a fact about the failure, not a hole in your evidence
SOURCE: dxdev.com/blog/the-silence-in-the-log-was-the-bug
WHAT HAPPENED: A customer reported that a helper account got an error saving part of a shared tool, while the account owner's own edits from the same tool saved fine. The internal error records had nothing matching the failure window, which read at first like a logging gap. Reproducing the exact failure as the actual reporting account, using a staff tool built for that purpose, showed the real shape of the problem: the save screen could be reached from three different tabs, but its save logic only recognized two of them. Reached from the third, it displayed a generic failure message and stopped before ever sending anything. That explained the empty records completely, because nothing had actually been sent to fail against.
THE RULE: A user-facing error with no matching internal record is not automatically a logging problem. It can mean the failure happened before anything was ever sent out, which narrows the investigation to "what stopped this from firing" instead of "what happened once it arrived." Consider that possibility before assuming your own recordkeeping dropped something.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Any user-facing error shown before a request is actually sent, where the message doesn't distinguish "never sent" from "sent and rejected."
2. Any shared action that can be triggered from more than one starting point, where the handling logic only recognizes a subset of those starting points.
3. Any support process that treats "no matching internal record" as inconclusive by default, rather than as a lead worth chasing on the sending side first.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
