Catch-All Mappings

## The request journal, and what reads from it WireMock keeps an in-memory **request journal**: an ordered record of every request the server has received, each entry pairing the request as it arrived with the stub that matched it and the response that went back. Serving traffic does not depend on it. Matching an incoming request against the registered mappings, choosing a reply and writing it to the socket all happen whether or not an entry is stored. The journal exists for one purpose — so that a test can ask, afterwards, *what did my code actually send?* Every part of WireMock's verification surface reads from that store: - `verify(...)`, with count matchers such as `exactly(`, `moreThanOrExactly(` and `lessThan(`, asks the journal how many recorded requests match a pattern. - `findAll(...)` returns the matching entries as `LoggedRequest` objects, so a test can inspect the path, query string, headers and body that arrived. - `getAllServeEvents()` returns the whole record, one `ServeEvent` per request served. - The admin API exposes the same store over HTTP: `GET /__admin/requests`, `POST /__admin/requests/count` and `POST /__admin/requests/find`. Take the journal away and all four lose their input at the same moment. ## What the flag actually does `--no-request-journal` is a WireMock start-up option, given on the standalone command line or expressed as `wireMockConfig().disableRequestJournal()` when the server runs embedded. It does not shrink the journal, sample it, or keep a summary of it. It replaces the store with a disabled one, and the disabled journal **raises `RequestJournalDisabledException`** from the count, the matching-request lookup, the serve-event list and the journal removals. WireMock's admin layer turns that into a result reporting the journal as disabled rather than a number, so the caller gets a failure instead of an answer. The important word is *abolished*, not *degraded*. There is no partial history to fall back on, no window of recent requests, not even a zero count a test could interpret. The correct mental model is that the server has stopped remembering, so no question about the past has an answer at all. ## Why anyone turns it off - **Memory.** The journal grows with every request, so an instance that lives for hours behind a soak run or a shared CI service accumulates entries steadily. Switching it off removes that growth outright. - **A copied command line.** One team sets it for one long run; the flag then travels into a Compose file or a CI job that other suites reuse without reading. - **Confusion with output.** Someone conflates the recorded journal with console noise and reaches for this flag when they meant `--verbose` or a logging setting. Only the first is a real reason, and it is a memory decision rather than a testing one. On any instance a suite verifies against, it is the wrong trade. ## What it costs a ferry-timetable suite | Question the test wants to ask | Journal on | Started with `--no-request-journal` | |---|---|---| | Did the client call `GET /v1/routes/DOV-CAL/departures`? | `verify(getRequestedFor(urlPathEqualTo("/v1/routes/DOV-CAL/departures")))` answers it | the call reports the journal disabled | | Which `date` parameter did it send? | `findAll(...)` returns the `LoggedRequest` | no record exists to inspect | | Did it fire the departure lookup twice? | a count matcher answers | unanswerable | A suite in that state can still assert on what the client did with the response — the parsed departures, the rendered timetable — but it cannot assert anything about the request. If the client silently stopped sending `date`, or began calling a stale path, nothing objects: a broad enough mapping still replies, and the record that would have shown the difference was never written. ## Why it belongs beside a catch-all mapping A mapping broad enough to answer everything means no request can fail to match. A disabled journal means no request can be checked after the fact. Either alone is recoverable; together they remove both halves of the evidence and the suite becomes a machine for producing green. The combination is nearly always accidental — one flag added for memory, one mapping added to unblock a build — but it is worth naming as a single failure mode, because the repair has two parts and they are undone in a particular order. Two neighbouring facts are worth carrying: 1. In MockServer, `mockserver.disableLogging` is the comparable switch: it disables the log and the processing of log events that verification reads from. 2. In Mountebank the same choice is made per imposter rather than per process, through `recordRequests`, which governs whether an imposter retains the requests it received for later inspection. ## Finding it, and undoing it The cheapest check is to ask the instance itself. In WireMock, `POST /__admin/requests/count` with a request pattern returns a count while the journal is live and reports the journal as disabled when it is not, which is a one-line probe for a CI job to run before any suite that verifies anything. Undoing it is equally cheap: removing the flag changes no response and cannot turn a passing test red, because recording is a side effect of serving rather than part of it.