Your build depends on a Postman mock server whose replies changed with no commit in your repository — how do you respond?

## Why your own history explains nothing The first move is to stop looking where the evidence cannot be. A Postman mock server answers with the **saved examples inside the collection** it was created from, and that collection lives in an **account**, not in a file your repository tracks. So when the replies change, there is no commit to blame, no diff to read, and no reviewer to ask on your side. Candidates who spend the first stretch bisecting their own history are answering a different incident. The right framing to say out loud: **the dependency changed without your dependency graph changing.** Your build pinned a URL, not a version of a reply set. ## What actually happened Almost always one of these, and they are distinguishable by asking, not by digging: - somebody with collection edit rights **edited or replaced a saved example** while working on something unrelated; - somebody **added or reordered** requests, and the example the stand-in now answers from is not the one it answered from yesterday; - the collection was **replaced wholesale** by an import or a bulk tidy-up; - **access changed** — the account, or your ability to reach it, is no longer what it was. Note what is *not* on that list: your code, your deploy, and the real service behind the stand-in. Whether the canned reply still resembles the real dependency is a **fidelity** question owned by other material; here, the stand-in changed because a person changed it. ## The sequence to run 1. **Capture the difference.** Record what the stand-in returns now and what your consumer expected. That artefact is the only evidence you will own at the end. 2. **Establish custody.** Identify which account holds the collection and who is admitted to edit it. This is a people question, and it is the fastest one. 3. **Ask the holders, plainly.** "Did anyone touch the examples in this collection?" — in most incidents this closes it inside minutes. 4. **Decide the immediate unblock.** Pin your consumer to a copy of the replies you hold yourself, so the pipeline stops depending on an answer you cannot see change. 5. **Write the decision down** where your team reviews things, since the cause will never appear in your history. ## Symptom to source | What you observe | Where the change happened | Where to look | |---|---|---| | Reply body differs, same call | a saved example was edited | the collection's holders | | A call that worked now misses | requests added or reordered | the collection's holders | | Everything fails at once | access or the account changed | your account relationship | | Only your branch fails | your consumer, after all | your own diff | ## Hardening the arrangement The fix is rarely "be more careful"; it is to change what the pipeline depends on: - **Keep the expected replies in your repository.** Then a change is a diff, reviewed by you, revertible by you — and the hosted stand-in goes back to being a convenience. - **Assert your expectation in your own tests**, so a changed reply fails in a place you own rather than three services downstream. - **Move the stand-in you depend on to something you start and operate**, if the pipeline genuinely needs one. That is a different subject with its own tooling; the point here is the custody change, not the tool. - **Reserve the hosted stand-in for exploration** and for consumers who can tolerate a surprise. - **Agree who announces edits**, if you must keep the dependency. It is a weak control — it is a promise, not a gate — but it is better than silence. ## What not to conclude - Do **not** conclude the stand-in "rebuilt itself" from the real service. It answers from saved examples; nothing regenerates them for you. - Do **not** conclude that a stricter permission would have prevented it. The reply set is the collection, so the edit right is the ordinary collection edit right — the arrangement has no separate gate to tighten. - Do **not** conclude that a retry, a longer timeout or a cache flush is a fix. The dependency's content changed; making the call again gets the new content again. - Do **not** treat it as a fidelity incident. Nothing about the real service is implicated by somebody editing a document. ## The senior signal What an interviewer listens for is whether you reach for **custody** rather than for a debugger. The strong answer says: the reply set is not mine, the edit is not in my history, the people who can change it are the people who can edit that collection — so my remediation is to own a copy of what I depend on, not to investigate harder next time.