lying-status

The lying status

Status and work travel on different paths. The work is a write, a job, a stream, a sync. The status is a flag, a response code, a progress record, a toast. Nothing makes the two atomic, so whenever the work fails after the status was committed, or the status is computed from something other than the work, the two diverge and the interface reports something that did not happen.

This is the archetype Crumbtrail is strongest on, for a structural reason: the product records the status plane and the work plane separately and can therefore contradict one with the other. Most of the queries below exist to put those two planes side by side.

Symptom

The interface said saved, sent, applied, synced, imported, complete, or showed a green check. The effect is missing, partial, or smaller than reported. Nothing errored.

Variants that are the same archetype: a progress record stuck at in progress with nothing running behind it; an import that reports a row count larger than the rows that exist; a job marked done that left work behind; a response with a success status whose body describes a failure.

What Crumbtrail can see

The status plane and the work plane, and both are ordinary parts of a recording:

• The status plane: response status codes, response bodies, console output, and the interface events around them. Bodies are summarized when large and sensitive fields are replaced with a redaction marker, but a count or a flag in a body normally survives intact.
• The work plane, where the database adapter is installed: row changes with the table, the primary key, the operation, the before and after column values, the request id that caused them and the call site file and line. This is the ground truth a status can be checked against.
• The middle: backend request start, end and error records with the route, the status code and the duration, where the backend SDK is installed. This is what tells you whether the status came from the same process that did or did not do the work.