# Diagnose an event that parsed but meant the wrong thing

When records look plausible but are wrong, trace how the consumer interpreted the message. Successful deserialisation can hide a semantic change.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Start with one incorrect business result

Choose a concrete affected record. Establish what the result should have been and which authoritative evidence supports that expectation. Avoid beginning with a broad replay that might repeat the same mistake across more records.

Capture the event identity, producer version, contract version, consumer version and processing time. Keep sensitive payloads in the approved investigation system rather than copying them into general chat or dashboards.

If the consumer can still create harmful effects, pause the relevant path while preserving incoming work. A narrow pause by event type or affected scope may protect unrelated processing, but only if that boundary is reliable.

## Compare meaning at each step

Inspect the original message, the converted internal object and the stored outcome. This separates producer errors from translation errors and later business logic.

Suppose an amount of 1250 was intended as minor units but displayed as 1250 dollars. Both values can fit the same numeric schema. Check the documented unit, the producer's calculation and the consumer's conversion. A schema version alone cannot explain an undocumented unit change.

Look for default values, timezone conversions, enum fallbacks and missing-field handling. These paths often make unexpected input appear valid. Record the first point at which the interpretation diverges from the contract.

## Bound the affected population

Identify the release window and the exact condition that triggers the error. Query by version and relevant field presence where possible. A time range alone can include unaffected messages from another producer or miss delayed deliveries.

Distinguish incorrect stored projections from external effects already performed. Rebuilding a report may be straightforward. Reversing a notification, dispatch or payment needs the relevant business recovery process.

Preserve a list of affected event and entity identities with their repair state. This makes a resumed repair less likely to repeat work or overlook a failed item.

## Repair with a corrected interpretation

Test the fix against the original failing message and adjacent cases. Run a small repair sample into an isolated output before changing production state.

Use duplicate protection and reconciliation during replay. Confirm that the corrected result matches independent business evidence, then resume traffic under observation.

Close the incident by updating the contract example and regression fixture. The useful lesson is the precise ambiguity that escaped review, not a general instruction to improve validation.

## Sources

- [OWASP: logging guidance](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)