5 ms·

Given what Pushover does, I would say it is reasonable. It is a text notification service, not a bank instructions processor. "I'm not receiving any notificatio

by _xnmw 3y ago

Given what Pushover does, I would say it is reasonable. It is a text notification service, not a bank instructions processor. "I'm not receiving any notifications" is likely to be a much more common customer complaint than "my message got truncated". Given that many of the users would not be coding the API integration themselves but using a tool like Zapier, it is reasonable to expect that they don't do text processing on the client side, and it would be the server's responsibility to deal with overflow text.

JimDabell 3y ago
Silently doing the wrong thing / silently discarding user data is bad engineering because it hides an error condition. You want failures like this to be loud not silent, especially if they are infrequent. If a client desires this behaviour, then add a `truncate=true` flag that has to be explicitly passed.
- madsbuch 3y ago
  What would you do in the case, where a developer never anticipates that a message goes above the limit, and hence does not catch and process that category of errors. Later the software is being repurposed, and some low amount, eg. 1%, goes about. But this error is silent.
  - fardo 3y ago
    If possible, redesigns preceded by targeted warning emails sent to business customers based on message length stats, with a timetable for when the fix will rollout. 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.
  - midasz 3y ago
    In semver, that's a major version upgrade since it changes the API without being backwards compatible. API consumers have responsibilities too.
  - JimDabell 3y ago
    > What would you do in the case, where a developer never anticipates that a message goes above the limit, and hence does not catch and process that category of errors. Later the software is being repurposed, and some low amount, eg. 1%, goes about. 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.
lijok 3y ago
Imagine having the financial promotion disclosures truncated off, unbeknownst to you, and getting your operating license taken away by the FCA.
- madsbuch 3y ago
  Imagine that you think the financial promotion disclosures are sent, but they are not.
  - lijok 3y ago
    You would know, because in the alternative setup, it wouldn't fail silently
  - JimDabell 3y ago
    Sorry, that solution doesn’t work. The API in question is designed to send push notifications. Push notifications are delivered by each platform on a best-effort basis. You simply cannot rely upon any particular push notification being delivered. If somebody is sending a disclosure in a separate notification to the message that needs the disclosure, they are already running afoul of the law because they have no way of ensuring the disclosure is delivered. The only way for an API like this to operate correctly is to reject invalid messages and not truncate. Silent data mangling is not acceptable.

by _xnmw 3y ago

JimDabell 3y ago

Silently doing the wrong thing / silently discarding user data is bad engineering because it hides an error condition. You want failures like this to be loud not silent, especially if they are infrequent. If a client desires this behaviour, then add a `truncate=true` flag that has to be explicitly passed.

madsbuch 3y ago
What would you do in the case, where a developer never anticipates that a message goes above the limit, and hence does not catch and process that category of errors. Later the software is being repurposed, and some low amount, eg. 1%, goes about. But this error is silent.
- fardo 3y ago
  If possible, redesigns preceded by targeted warning emails sent to business customers based on message length stats, with a timetable for when the fix will rollout. 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.
- midasz 3y ago
  In semver, that's a major version upgrade since it changes the API without being backwards compatible. API consumers have responsibilities too.
- JimDabell 3y ago
  > What would you do in the case, where a developer never anticipates that a message goes above the limit, and hence does not catch and process that category of errors. Later the software is being repurposed, and some low amount, eg. 1%, goes about. 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.

lijok 3y ago

Imagine having the financial promotion disclosures truncated off, unbeknownst to you, and getting your operating license taken away by the FCA.

madsbuch 3y ago
Imagine that you think the financial promotion disclosures are sent, but they are not.
- lijok 3y ago
  You would know, because in the alternative setup, it wouldn't fail silently
- JimDabell 3y ago
  Sorry, that solution doesn’t work. The API in question is designed to send push notifications. Push notifications are delivered by each platform on a best-effort basis. You simply cannot rely upon any particular push notification being delivered. If somebody is sending a disclosure in a separate notification to the message that needs the disclosure, they are already running afoul of the law because they have no way of ensuring the disclosure is delivered. The only way for an API like this to operate correctly is to reject invalid messages and not truncate. Silent data mangling is not acceptable.