integration-forensicslisted

# integration forensics When your code talks to a system you do not control, the bug is usually not in your code. It is a **false belief about what the other side does**, and no amount of reading your own code will surface it. So the method inverts. Do not reason about the code. Establish what actually crossed the wire, then reason about the difference between that and what you expected. > **The documentation describes intended behaviour. You need observed behaviour, > and they are different systems.** ## Step 1, get the raw payload, before anything touches it Not the parsed object. Not the logged summary. The bytes. Most integration bugs are invisible after parsing, because the parse is where the wrong assumption gets applied. A field arrives as a string instead of a number, an array has one element instead of five, a key is absent rather than null, and the parsed object looks perfectly reasonable. If there is no raw log, adding one is the first fix, not a detour. Log the untouched body and the headers, on every inbound call, before validation. Keep a rolling window. This one change resolves more integration bugs than any amount of instrumentation downstream, and it costs almost nothing. Then **reproduce from a stored payload, never from live traffic.** Live traffic is not reproducible, arrives when it wants, and cannot be replayed against a fix. A saved payload is a test case. ## Step 2, the catalogue Nearly every third-party integration bug is one of these. Work