In Mountebank, what do recordRequests, mb save and mb replay do with kayak-rental traffic?

middleshould knowfreq 49%

answer

three pieces, not one command
the imposter keeps what it is sent
proxies leave recorded stubs behind
save writes out, replay removes proxies
recordRequests is set per imposter

basics

~20 s

In Mountebank, recordRequests makes an imposter keep every request it receives, and a proxy response saves the real replies as new stubs. mb save writes that configuration to a file; mb replay strips the proxies so recorded stubs answer.

solid answer

~50 s

Mountebank splits recording across three pieces rather than one switch. Mountebank's recordRequests: true on an imposter makes it retain every request it receives — GET /fleet/boats?site=lower-weir, POST /rentals — readable back from GET /imposters/:id, with numberOfRequests reporting how many arrived. Separately, a Mountebank stub whose response is a proxy to https://kayaks.riverbend.example forwards the call and saves the real reply as a new stub on that imposter, so recorded answers accumulate in front of the proxy. mb save then writes the running configuration — imposters plus everything the proxies captured — out to a file you can restart from. mb replay flips the running instance out of record mode by removing the proxy responses, so the imposter answers from the recorded stubs alone. Starting mb with --datadir holds that state in a directory rather than in memory.

Mountebank splits recording across three pieces rather than one switch. Mountebank's `recordRequests: true` on an imposter makes it retain every request it receives — `GET /fleet/boats?site=lower-weir`, `POST /rentals` — readable back from `GET /imposters/:id`, with `numberOfRequests` reporting how many arrived. Separately, a Mountebank stub whose response is a `proxy` to `https://kayaks.riverbend.example` forwards the call and saves the real reply as a new stub on that imposter, so recorded answers accumulate in front of the proxy. `mb save` then writes the running configuration — imposters plus everything the proxies captured — out to a file you can restart from. `mb replay` flips the running instance out of record mode by removing the proxy responses, so the imposter answers from the recorded stubs alone. Starting mb with `--datadir` holds that state in a directory rather than in memory.

code

json · 12 lines

json

{
  "port": 4547,
  "protocol": "http",
  "recordRequests": true,
  "stubs": [
    {
      "responses": [
        { "proxy": { "to": "https://kayaks.riverbend.example" } }
      ]
    }
  ]
}

go deeper

for a junior

Know that recordRequests makes a Mountebank imposter remember what it received, and that mb save and mb replay are separate steps run against an already-running instance.

for a middle

Explain why remembering requests produces no stubs, and why replaying before saving is the order that keeps a live proxy out of the saved configuration.

for a senior

Be ready to describe operating a long capture: where the state lives without --datadir, how an imposter grows while recording, and what you check before treating a saved file as a fixture.

for a principal

Own the standard across teams: which recording arrangement is house style, who may proxy to a live service, and how a saved configuration is reviewed before it is depended on.

Recording as three jobs, not one

Mountebank does not have a single record switch. It splits the work into three concerns that can be used independently, and understanding which one does what is most of the topic:

remembering requests — what arrived at the imposter, kept for you to read;
recording responses — turning what a real upstream returned into stubs on the imposter;
saving and replaying — moving that captured state out to a file, and taking the imposter out of record mode.

A person who has only met the first of these will say Mountebank records requests, which is true and incomplete: remembering requests produces no stubs at all.

Mountebank's recordRequests: what arrived

recordRequests: true is a field on the Mountebank imposter. With it on, the imposter retains each request it receives, and Mountebank's GET /imposters/:id returns them alongside the imposter's configuration. Mountebank's numberOfRequests reports how many the imposter has taken.

This is a diagnostic and verification facility, and its limits are worth stating precisely:

it tells you the kayak-rental client really did send POST /rentals with the body you expected;
it creates no stub and changes nothing about what the imposter answers;
it is scoped per imposter, so turning it on for one says nothing about the others;
the retained requests accumulate, so a long-lived imposter left recording grows for as long as it runs.

Mountebank proxy responses: what came back

The stub-producing half is a Mountebank stub whose response is a proxy pointing at the real kayak-rental service. When a request matches that stub, Mountebank forwards it, returns the genuine reply to the client, and saves that reply as a new stub on the imposter. Recorded stubs accumulate ahead of the proxy, so the same request served a second time can be answered from the capture rather than forwarded again.

Two things follow from that arrangement:

this, not Mountebank's recordRequests, is the mechanism that turns real kayak-rental traffic into a fixture set;
the two are orthogonal, and a recording session usually wants both — the Mountebank proxy to build the stubs, recordRequests to prove what was sent.

mb save and mb replay

These two are CLI commands against a running mb, and they do different things:

command	what it does
`mb save`	writes the running configuration — imposters and everything the proxies recorded — out to a file you can restart from
`mb replay`	takes the running instance out of record mode by removing the proxy responses, so imposters answer from their recorded stubs alone

The usual sequence is: start mb, create the imposter with a proxy and recordRequests, drive the kayak-rental client through it, then mb replay so nothing reaches the real service any more, then mb save so the captured set survives the process. Running them in the other order saves a configuration that still contains the proxies, which will happily call the live service again the next time it is loaded.

Persistence and Mountebank's --datadir

By default Mountebank holds imposter state — including the requests recordRequests retained and the stubs the proxies produced — in the process. Start mb with --datadir and that state lives in a directory instead. Two things follow:

state survives a restart of the mb process, so a long capture is not lost to a crash;
a long-running instance is not holding an ever-growing request list in memory.

mb save is still the step that produces a portable, reviewable artefact; Mountebank's --datadir is about where the running mb instance keeps its working state.

The flag not to reach for

Mountebank has a --mock command-line flag, and its own help text marks it deprecated in favour of recordRequests per imposter. It still exists, so it will appear to work and it will appear in older write-ups. Use the per-imposter field instead; it is the current surface, and it is scoped to one imposter rather than to the whole process.

How this compares

product	how a recording is armed	how the capture is persisted
Mountebank	`recordRequests` plus a `proxy` response on the imposter	`mb save` to a file; `--datadir` for working state
WireMock	`startRecording(...)` on a running server, or the launcher's `--record-mappings`	stub mappings, with large bodies extracted to body files

The shapes differ but the discipline does not. In both products the recorder is faithful rather than thoughtful: it keeps the credentials, the generated identifiers and the timestamps that happened to be in the kayak-rental traffic, and somebody has to read the result before it becomes a committed fixture set.

## Recording as three jobs, not one Mountebank does not have a single record switch. It splits the work into three concerns that can be used independently, and understanding which one does what is most of the topic: - **remembering requests** — what arrived at the imposter, kept for you to read; - **recording responses** — turning what a real upstream returned into stubs on the imposter; - **saving and replaying** — moving that captured state out to a file, and taking the imposter out of record mode. A person who has only met the first of these will say Mountebank records requests, which is true and incomplete: remembering requests produces no stubs at all. ## Mountebank's recordRequests: what arrived `recordRequests: true` is a field on the Mountebank imposter. With it on, the imposter retains each request it receives, and Mountebank's `GET /imposters/:id` returns them alongside the imposter's configuration. Mountebank's `numberOfRequests` reports how many the imposter has taken. This is a *diagnostic and verification* facility, and its limits are worth stating precisely: - it tells you the kayak-rental client really did send `POST /rentals` with the body you expected; - it creates no stub and changes nothing about what the imposter answers; - it is scoped per imposter, so turning it on for one says nothing about the others; - the retained requests accumulate, so a long-lived imposter left recording grows for as long as it runs. ## Mountebank proxy responses: what came back The stub-producing half is a Mountebank stub whose response is a `proxy` pointing at the real kayak-rental service. When a request matches that stub, Mountebank forwards it, returns the genuine reply to the client, and saves that reply as a new stub on the imposter. Recorded stubs accumulate ahead of the proxy, so the same request served a second time can be answered from the capture rather than forwarded again. Two things follow from that arrangement: - this, not Mountebank's `recordRequests`, is the mechanism that turns real kayak-rental traffic into a fixture set; - the two are orthogonal, and a recording session usually wants both — the Mountebank proxy to build the stubs, `recordRequests` to prove what was sent. ## mb save and mb replay These two are CLI commands against a *running* mb, and they do different things: | command | what it does | |---|---| | `mb save` | writes the running configuration — imposters and everything the proxies recorded — out to a file you can restart from | | `mb replay` | takes the running instance out of record mode by removing the proxy responses, so imposters answer from their recorded stubs alone | The usual sequence is: start mb, create the imposter with a proxy and `recordRequests`, drive the kayak-rental client through it, then `mb replay` so nothing reaches the real service any more, then `mb save` so the captured set survives the process. Running them in the other order saves a configuration that still contains the proxies, which will happily call the live service again the next time it is loaded. ## Persistence and Mountebank's --datadir By default Mountebank holds imposter state — including the requests `recordRequests` retained and the stubs the proxies produced — in the process. Start mb with `--datadir` and that state lives in a directory instead. Two things follow: 1. state survives a restart of the mb process, so a long capture is not lost to a crash; 2. a long-running instance is not holding an ever-growing request list in memory. `mb save` is still the step that produces a portable, reviewable artefact; Mountebank's `--datadir` is about where the running mb instance keeps its working state. ## The flag not to reach for Mountebank has a `--mock` command-line flag, and its own help text marks it deprecated in favour of `recordRequests` per imposter. It still exists, so it will appear to work and it will appear in older write-ups. Use the per-imposter field instead; it is the current surface, and it is scoped to one imposter rather than to the whole process. ## How this compares | product | how a recording is armed | how the capture is persisted | |---|---|---| | Mountebank | `recordRequests` plus a `proxy` response on the imposter | `mb save` to a file; `--datadir` for working state | | WireMock | `startRecording(...)` on a running server, or the launcher's `--record-mappings` | stub mappings, with large bodies extracted to body files | The shapes differ but the discipline does not. In both products the recorder is faithful rather than thoughtful: it keeps the credentials, the generated identifiers and the timestamps that happened to be in the kayak-rental traffic, and somebody has to read the result before it becomes a committed fixture set.

In Mountebank, what does mb replay actually change on a running instance?
It takes the imposters out of record mode by removing their proxy responses. Whatever those proxies already recorded stays behind as stubs, so the next kayak-rental call is answered from the capture instead of being forwarded upstream. Nothing about the requests `recordRequests` retained changes; replay concerns how the imposter answers, not what it remembers.
In Mountebank, where do the requests recordRequests keeps actually live?
In Mountebank they are held by the imposter and returned inside `GET /imposters/:id`, with `numberOfRequests` alongside. By default that is process state, so a restart loses them and a long-running instance keeps growing. Starting mb with `--datadir` moves that working state to a directory on disk instead.

saying these in an interview costs you the question

Thinks mb save is what performs the recording
Believes recordRequests creates stubs from the requests
Expects mb replay to re-send the recorded requests
Reaches for the deprecated --mock flag instead of recordRequests
Saves before replaying and keeps the proxies in the file

In Mountebank, what do recordRequests, mb save and mb replay do with kayak-rental traffic?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Recording as three jobs, not one

Mountebank's recordRequests: what arrived

Mountebank proxy responses: what came back

mb save and mb replay

Persistence and Mountebank's --datadir

The flag not to reach for

How this compares

▾common follow-ups2 questions

▾red flags5 flags

Recording as three jobs, not one

Mountebank's recordRequests: what arrived

Mountebank proxy responses: what came back

mb save and mb replay

Persistence and Mountebank's --datadir

The flag not to reach for

How this compares

answer

go deeper