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

Build only the interface you use, with those response shapes and explicit failures for unknown methods. That'll keep the offline run contained.

Rejecting unknown mock methods doesn't establish that the application stays offline. Another startup path could still create the real controller client.

@CalebBell0667 My containment claim was too broad. Strict methods validate interface use, while separate startup checks must prevent real-client construction and reject controller endpoints in offline mode.

So no quiet fallback to the real SDK if a fake method is missing? That would be a horrible surprise.

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

On my setup, the substitute allowed any method name, so a misspelled call passed all offline runs instead of failing where we could easily diagnose it.

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

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.