Inconsistent error reporting

The systems I maintain call several different partner APIs to get player account information. We noticed recently that one of the APIs returns seemingly inconsistent error messages when presented with invalid player account numbers. For example, if we ask for information on account number 123456789, the system returns a 404, meaning that the account was not found in the system. But if ask for account number 3420859494, the server returns a 500: internal server error. Very strange.

At first I thought it was that the account number was too long. Typically, the account numbers are eight digits, and the ones giving us errors were 10 digits in length. But when I requested account number 1420859494 (10 digits), I got a 404.

On a hunch, I tried the magic number 2147483647. Not surprisingly, that returned a 404. But 2147483648 returned a 500 error. What the heck?

The magic of 2147483647 is that it’s the largest signed integer that can be expressed in 32 bits. It appears that the API tries to convert the input to a 32 bit integer. If that conversion fails, the server throws an exception and returns a 500 internal server error.

This is the kind of error that unit testing is designed to ferret out. Had they tested the edge cases, they would have seen this inconsistent behavior and, one would hope, modified the code to handle it more reasonably.

I don’t know what to do about this. Their documentation doesn’t say specifically that the input must be a positive 32-bit integer, only that the value must be numeric. Based on the empirical evidence, I could put some validation on my end to ensure that users don’t enter account numbers larger than 2147483647, but there’s nothing preventing the API from changing underneath me and allowing larger numbers in the future. It’s unlikely that those in charge of the partner API would notify me of such a change.

4 comments to Inconsistent error reporting

  • Hi Jim, What is your advice in handling such scenarios? I have faced a few like this before. When we use a framework like some MVC ones that hand you a model object/type in your service request handling method, there is little control. Other option is to take in the input as string and try some boundary checks keeping the data as string and later convert to int. Even those have limitations. Most teams don’t worry much as their service reports an error anyhow. Like to hear your thoughts.

  • Jim

    Vivek: My issue is the inconsistency of the error. In my opinion, the system should always report the same error for an unknown account number. So if account number 12345 is “Not Found,” then account number 9876543210 should be “Not Found.” Or, if the system wants to differentiate between an account number that is not found, and an account number that is in the wrong format, then in the latter case they should return a 400, “Bad Request,” and a message indicating that the account number supplied is out of range or otherwise incorrectly formatted.

    In no case should the system return a generic “Internal server error” because the account number is not in the right format. That’s just lazy programming.

  • Hi Jim, I agree with you about the consistent error reporting.

    Actually, I wanted to pick your brain on how to handle 12345 and some out-of-range integer. 12345 or any valid integer is easy to ascertain that it is not an existing account number. The out-of-range input is tricky. Currently, what we are doing with the out-of-range input is treat like a string and trying to identify if it could lie in the valid integer range. I think it is crude. Was exploring if there are better and established ways for handling.


  • Jim

    Vivek: When I’m writing a Web API, if the string that the caller passed is not easily identifiable as valid input, then I reject it. For example, if the caller passed “A12345” and I expect the account number to be an integer, I will not try to pick the “12345” from the string. In my experience, the values I extract from making assumptions about what the caller meant are wrong as often as they are right. It’s best to tell the user, “account not found” or “account number is in an invalid format.”



A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.