@JoAbbott0070 Yes. Replaying our saved error response reproduces a parser bug. The always-true mock sailed straight past it, naturally.

Use a small substitute implementing only your required methods, matching the saved response contracts and rejecting unexpected calls. That should keep the run contained offline.

@JoAbbott0070 Contained how? A strict mock doesn't stop startup code constructing a real client somewhere else

You're right. i blurred two checks. The strict interface catches wrong calls; offline startup also needs to exclude the real client and reject controller endpoint configuration.

Should a missing substitute method always fail the offline run instead of falling back to the real SDK? I want that boundary to be unambiguous.

Exactly. Fail clearly. A missing method is something to implement or remove from your application, not a reason to reach the controller.

My substitute accepted arbitrary method names. A typo passed every offline run. The fake was exceptionally supportive and entirely useless for that mistake.

@ElenaBell0688 Would you check argument names too, or is matching the return value enough?

@RachelBarnes0609 Match the documented call signature too. Wrong arguments should fail clearly instead of getting a plausible canned response.

I tried that and found an obsolete helper call in our application. The permissive mock had accepted it without complaint.

Have you tied the saved examples to their SDK version? A realistic response from another version could still teach the substitute the wrong behaviour

Our saved examples have the SDK source identifier and matching documentation. I'll keep those attached; loose response files would lose that context.

Can I just invent the missing error cases? We won't have captures for absolutely everything.