In Mountebank, what is the fault response type, and which two values does it take?

## A Mountebank response object picks exactly one type A Mountebank imposter holds `stubs`, each stub holds `predicates` that decide when it applies and a `responses` array that decides what it answers. Each object in that array names exactly one response type, and the choice is exclusive: - `is` — a canned reply you write out literally. - `proxy` — forward the request to a real upstream and use what comes back. - `inject` — run a JavaScript function and use its return value. - `fault` — do not produce a response at all; break the connection. Because they are mutually exclusive, `{ "is": {...}, "fault": "..." }` is not a way to send a reply and then break something. If you want a fault, the response object contains a fault and nothing else. ## The fault type and its two values Mountebank's `fault` accepts **exactly two** values: - `CONNECTION_RESET_BY_PEER` - `RANDOM_DATA_THEN_CLOSE` On a cattle-auction Mountebank imposter, a stub that makes bid submission die on the wire is a predicate matching `POST /auctions/v1/lots/48/bids` paired with a response of `{ "fault": "CONNECTION_RESET_BY_PEER" }`. There is no third value, and in particular there is no Mountebank equivalent of an empty-response fault or a malformed-chunk fault. ## The collision with WireMock's enum This is the sharpest naming trap in the whole stub-server space, and it is worth being explicit about. Both of Mountebank's fault values are spelled character for character like two of WireMock's four `Fault` enum constants. | value | Mountebank `fault` | WireMock `Fault` | |---|---|---| | `CONNECTION_RESET_BY_PEER` | yes | yes | | `RANDOM_DATA_THEN_CLOSE` | yes | yes | | `EMPTY_RESPONSE` | no | yes | | `MALFORMED_RESPONSE_CHUNK` | no | yes | The consequence is practical rather than academic. A reviewer who searches a codebase or a document for `RANDOM_DATA_THEN_CLOSE` learns nothing about whether the sentence around it is true, because the token exists in both products. Only the attribution carries the fact. So: 1. Write "Mountebank's `fault` response type" or "WireMock's `Fault` enum" — never the bare constant on its own. 2. Never quote the four-value list as Mountebank's; it has two. 3. Never assume a Mountebank imposter will accept `EMPTY_RESPONSE` because you have seen the name somewhere. It will not. The two products also differ in shape, not only in vocabulary. WireMock attaches a fault as a decoration on its reply builder, `aResponse().withFault(...)`, whereas Mountebank replaces the whole response object. So a stub cannot be translated between them by substituting one identifier for another. ## fault is a response type, not a behavior Mountebank has a separate concept called **behaviors**, and there are exactly five of them: `wait`, `copy`, `lookup`, `shellTransform` and `decorate`. Behaviors post-process a response that already exists — they wait before sending it, copy values into it, look values up, transform it through a shell command, or decorate it with a function. `fault` is not among them, and it could not be: there is no response for a behavior to post-process, because a fault is the absence of one. Listing `fault` among the behaviors is one of the two classic Mountebank errors. The other is listing `repeat`, which is not a behavior either — it is a field on a response controlling how many times that response is used before the array moves on. ## Writing it so a reader cannot mis-read it A few habits make the difference between a statement that can be checked and one that cannot: - Name the product in the sentence, every time, not just once per paragraph. - Name the container as well when it disambiguates: "Mountebank's `fault` response type", "WireMock's `Fault` enum constant". - When you enumerate, say how many there are — two for Mountebank's fault, four for WireMock's enum, five for Mountebank's behaviors — because the counts are the fastest way for a reader to spot a list that has drifted. - Keep the fault stub obvious in the Mountebank imposter: a dedicated lot number or path makes it clear which endpoint of the cattle-auction API is deliberately hostile. Get those right and the shared vocabulary stops being a hazard. Get them wrong and you produce a sentence that survives every automated check and is still false, which is exactly the failure mode this area of tooling is notorious for.