Is fixing integer overflow with wrong error message considered a feature flaw or a functional bug?

[juliusgambe]

Problems caused by extreme user behaviors:
If the problems can only happen in case of deliberate sabotage (e.g., user entered a 30-digit telephone number), in which case it should not be considered a bug.
However, if such input can be entered by a user mistake, they should not cause harm e.g., such mistakes should not crash the app, corrupt the data, or make it unusable.
Problems caused by integer overflows -- apply the guideline in the previous point.

According to the definition of a functional bug, we should follow the above guideline for integer overflow. Currently, this problem occurs when trying to specify the ID that is unique to our Customer or Delivery (Different from AB3 Index). When inputting the maximum integer, the error message specifies that the ID should me more than 0 when clearly it is more than 0. As the error message does not correspond to the incorrect action of the user, can this be considered a functional bug? A user can accidentally input this large integer number by accident.

If it is not possible to fix, would this be possible to be added as a planned enhancement?

[damithc]

@juliusgambe As the error message is incorrect for this case, it can be fixed.

[juliusgambe]

@juliusgambe As the error message is incorrect for this case, it can be fixed.

In that case, just to double confirm that it would be okay to modify all error messages that incorrectly states this message?

[damithc]

@juliusgambe Yes, but only if the current message is strictly incorrect (not 'can be better, more precise, etc.').
After taking another look at your case, I think it should be enough to clearly state in the UG that any index inputs should be 1 .. MAX_INT. As MAX_INT is an extreme input, dealing with it can be postponed, provided such inputs don't cause any harm currently. Sorry I didn't catch it in my earlier reply.

[juliusgambe]

@juliusgambe Yes, but only if the current message is strictly incorrect (not 'can be better, more precise, etc.'). After taking another look at your case, I think it should be enough to clearly state in the UG that any index inputs should be 1 .. MAX_INT. As MAX_INT is an extreme input, dealing with it can be postponed, provided such inputs don't cause any harm currently. Sorry I didn't catch it in my earlier reply.

Just to clarify, if we add a definition for what is a valid ID which would be from 1 to MAX_INT in our UG and for any commands that expect an ID, the ID parameter it should be from 1 to MAX_INT, then for error messages that currently state "ID should be a positive integer" and if we key in a number more than the MAX_INT, 2147483648, and it throws this error message, it would still be incorrect right and we should rectify this? As we are not making it more specific as it is incorrect in the first place.

Unless, the error message states that "ID must be a positive integer and must be a valid ID", then we cannot change this as our UG defines what is a valid ID right? (Which is 1 to MAX_INT)

[damithc]

Then for error messages that currently state "ID should be a positive integer" and if we key in a number more than the MAX_INT, 2147483648, and it throws this error message, it would still be incorrect right and we should rectify this? As we are not making it more specific as it is incorrect in the first place.

Yes, it is incorrect but no need to rectify it in v1.4 if it can be considered an extreme input. For an index in AB3, this would be an extreme input but it may be different for your app. If you think this is not an extreme input in the context of your app, you can update the error message accordingly.