---
title: "The Complaint With No Record Anywhere"
canonical: https://dxdev.com/blog/2026-07-21_the-complaint-with-no-record-anywhere/
datePublished: 2026-07-21
---
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 the customer ended up filling in the rest by hand. On the surface it read like a permissions problem: a new helper account, a partial failure, a familiar shape.

## Nothing on our side matched it

The first thing checked was our own internal error records for anything matching that failure window. There was nothing. No trace of that save attempt arriving and failing. Normally an empty record like that is a bad sign in a support investigation, because it means the easiest source of truth has nothing to offer.

Rather than stop there, the exact failure got reproduced using the helper account itself, through a staff tool that lets support see precisely what a specific customer sees. The error came up right on cue, screenshot and all. Still nothing in the records for that window. That absence is what actually pointed at the real answer, once it stopped being treated as a hole in the evidence and started being treated as a fact about what had happened.

## Following the actual path, not the account

The save screen in question could be reached from three different places in the tool, three different tabs showing different views of the same schedule. It turned out the save logic only recognized two of the three. Reached from the third tab, it hit a dead end that displayed a generic "something went wrong" message and stopped right there, without ever sending anything out at all.

That explained everything at once. The records were empty because there was genuinely nothing to record, no request ever left that screen to fail against. It also explained the partial-save pattern that had looked like a permissions issue: edits made from the two working tabs went through fine, and edits made from the third tab hit the dead end every time, for anyone using it, helper or owner. Checked directly, the account owner got the identical failure from that same tab.

## Fixing where the gap actually was

The fix connected that third tab's save action to the same working path the other two already used, rather than patching the dead end to fail a little more gracefully. Checked again live, on the exact account and the exact save that had failed before, it went through cleanly, and the data that came back matched a snapshot taken right before the fix, confirming nothing else had changed except the request now actually firing.

## What the silence was actually saying

The instinct, faced with a customer report that leaves no trace anywhere in your own systems, is to doubt the report or assume your recordkeeping swallowed something. Neither was true here. Our records weren't broken. They were correctly reporting that nothing had happened on our end, because nothing had. A failure that happens before a request ever gets sent doesn't leave a partial trail behind it. It leaves silence, and silence, read the right way, is just as informative as a full record. It says: stop looking at what happened after the request arrived, and start looking at what kept the request from being made at all.