In WireMock, when does --print-all-network-traffic tell you what the near-miss report cannot?

## What the near-miss report is actually comparing WireMock's near-miss report is a comparison of *parsed* structures. By the time a WireMock `LoggedRequest` reaches the scoring code, the bytes that arrived on the socket have already been turned into a method, a URL, a header map, a cookie map and a body, and the report tells you how that parsed object differed from each stub mapping's matchers. That is what you want almost every time: it is compact, it is ranked closest-first, and it names the field. It is also, by construction, blind to anything that went wrong *before* the parse. If the request WireMock parsed is not the request your client believed it sent, the diff will be accurate and useless at the same time — faithfully reporting a difference whose cause is one layer down. ## What WireMock's --print-all-network-traffic adds Starting WireMock with `--print-all-network-traffic` makes the server write the raw incoming and outgoing traffic of every exchange it handles to its console: the request line, every header verbatim, and the body as it came off the wire, then the same for the response. It is an observation switch and nothing more. It does not relax a matcher, promote a near miss into a match, or change which mapping serves a request; it changes only what you can see about an exchange whose outcome has already been decided. ## The failures that only show in the raw bytes - **Header names or values the parser normalises.** Duplicate headers, unexpected casing, or a value with trailing whitespace can read as a plain mismatch in a diff and be immediately obvious in the dump. - **Transfer encoding.** A chunked or compressed body means the thing your matcher was compared against is not the thing your client's own logger printed. - **Content type and multipart boundaries.** A body that is well-formed JSON to your eye may have arrived under a content type the mapping does not expect, or wrapped in a multipart envelope. - **Truncation and early close.** A client that cuts the body short produces a body mismatch with no visible cause; the dump shows how many bytes actually arrived. - **Requests you did not know were being made.** A retry, a redirect follow, or a health probe appears in the dump even when you were only looking at one endpoint. ## A working order for a vineyard harvest-log mismatch 1. Read the near-miss report first. It is cheap, it is ranked, and nine times out of ten it names the field that differed. 2. If the report says the body differed and the two bodies look identical to you, stop trusting the parsed view. 3. Restart WireMock with `--print-all-network-traffic` and reproduce the single failing call — the `POST /vineyard/harvest-logs` that should have returned 201. 4. Read the dump against the mapping: the exact bytes, the exact header spelling, the content type. 5. Turn the flag back off before the suite runs again. ## The cost, and how to keep it contained The dump is unranked, unscored and complete. It prints the exchanges that matched perfectly alongside the one that did not, and it prints bodies in full. On a suite that exercises a harvest-log API a few hundred times that is a great deal of console output to read by eye, and on an instance more than one person is using it is noise everybody else has to scroll past. - Turn it on for one reproduction, not for a suite run. - Reproduce with a single call — a hand-written client call is far easier to read in a dump than a whole test. - Turn it off again as soon as you have the bytes, because leaving it on hides the next failure inside the volume it generates. - Keep the near-miss report in the loop even while the dump is on; the two answer different halves of the question. ## What the flag does not do It is worth being precise about the boundary, because this flag gets described loosely. It does not alter matching, so a stub that failed to match before will fail to match after. It does not score anything, so it cannot rank candidates the way the near-miss report does. And it is not a substitute for that report: the productive order is always report first, bytes second. WireMock's near-miss report tells you which field the server thinks differed; WireMock's `--print-all-network-traffic` tells you what actually arrived, which is the only thing that can settle an argument between the two. Diagnosing an unmatched request is really a question of which layer you have stopped trusting, and these two tools sit either side of exactly that line.