This is exactly the type of scenario I was thinking about.
> But this error is silent.
You’re conflating two different systems; the API and the client that accesses it. These are different systems worked on by different people in different organisations.
This error is not silent at all. It’s correctly flagging the error as soon as it happens. The client is told in no uncertain terms that the call failed. This is good engineering. Hiding a problem only makes it harder to detect, which prolongs time to fix. Errors should be flagged immediately and loudly. For an HTTP-based API that means responding with a 4xx class error and a response body containing an informative message. So – not silent at all.
Separately, in a different organisation, some client developer has screwed up by ignoring the response from an API call. In the general case, you can’t fix this externally. Bad developers who assume all their calls succeed and don’t check error conditions are going to make that mistake all over their code and their shortcomings are going to manifest as numerous bugs. Furthermore, whomever reviewed their code missed something obvious – these kinds of bugs are easy to spot in code review. So generally speaking, if you’re asking what I would do then the answer is nothing. I’m not responsible for fixing somebody else’s dysfunctional team in somebody else’s organisation and I’d just be scratching the surface by trying to work around just one of their bugs at the expense of my own service’s quality.
In this particular case, however, you can surface 4xx class errors in a number of ways if you really wanted to, e.g. email the client a daily report of all client errors. But you should be designing your API so that correct usage provides a robust solution and that means rejecting invalid data immediately.
If that data doesn’t exist, public announcement that the API is breaking long messages without the new parameter.
If the API can’t be broken, version the API and break it in the new one and for new customers.
In all cases, disclosure in the documentation - If you know there’s a limit and you still exceed it, at that point, as the kids say, FAFO.