
A New Enum Value Breaks Clients That Trusted Your List
A new enum value passes every schema diff and still breaks clients that validate responses. Read as text, send from a closed list, and mark it Breaking.
10 posts

A new enum value passes every schema diff and still breaks clients that validate responses. Read as text, send from a closed list, and mark it Breaking.

A video passes through several paid layers. We measured some of them; the rest are price lists and estimates, and each row says which.

Paying a vendor feels like it should authorise charging the client. It does not, and the wording that says otherwise keeps coming back into the rules.

No /openapi.json, no generator, no spec to drift. The machine-readable entry point is the MCP server's tools/list — and that turned out to be the honest choice, not the lazy one.

A 3% aspect mismatch is a rounding error. A 40% one is a different video. The threshold between them decides whether you refuse before the bill or apologise after.

An unmet parameter should come back named. We learned why the hard way: two warnings went missing for weeks and every test stayed green.

Six blockers across four consecutive stories, and the two reviews agreed on one of them. Here is what running both actually cost us, and the rule we ended up with.

Our render container reported 32 cores when it had 4. Remotion sized its defaults from that and OOMed. Five confident diagnoses died before the answer turned up in a version field nobody had thought to print.

Our billing rule said: failed run after a paid vendor call means we charge. It sounded fair. On a run that only paid for speech, it was false, and it cost a customer.

Teams blame MCP when agents fumble their tools. We shipped an MCP server for a video API and found the real defect: offering a field you answer with a 400.