Deciphering validation-error, expectedType matches value

[HemalR]

I get this sporadic error for one of my methods:

{
	description: 'Part number must be of type Number',
	errorType: 'ClientError',
	name: 'ClientError',
	error: 'validation-error',
	details: [
		{
			name: 'partNumber',
			value: 1,
			type: 'expectedType',
			dataType: 'Number',
			message: 'Part number must be of type Number',
		},
	],
};

The value in question 1 is of the type defined in the schema: Number. Am I misreading something in the error? Would it make sense to modify the message to say: X must be of type Number but received {actual received type}?

The fact that it is sporadic (for a method that is fired a few thousand times a day I get this error 1-2 times) is making it difficult to debug. Any tips/suggestions/obvious oversights in the error message above much appreciated.

Thanks

[github-actions]

Thank you for submitting an issue!

If this is a bug report, please be sure to include, at minimum, example code showing a small schema and any necessary calls with all their arguments, which will reproduce the issue. Even better, you can link to a saved online code editor example, where anyone can immediately run the code and see the issue.

If you are requesting a feature, include a code example of how you imagine it working if it were implemented.

If you need to edit your issue description, click the [...] and choose Edit.

Be patient. This is a free and freely licensed package that I maintain in my spare time. You may get a response in a day, but it could also take a month. If you benefit from this package and would like to see more of my time devoted to it, you can help by sponsoring.

[aldeed]

I agree generally that it could be helpful to state what incorrect type was found. In JavaScript it isn't always quite so simple to just get a string name for the type. I think this could be done, but exactly how the actual type is determined would need to be implemented carefully based on exactly how and why the type check failed.

Regarding the actual error, the check that causes this is if (typeof keyValue !== 'number' || isNaN(keyValue)). So my only thought is that there is some browser error or some package overriding the implementation of the isNaN global, causing a false failure.

[HemalR]

Thanks for the suggested possible line of investigation to get to the bottom of this @aldeed

Just thinking along the lines of the isNan implementation being overridden - wouldn't that lead to subsequent method calls (a couple of seconds later, by the same client on the same browser during the same session) also failing? That hasn't been the case though with a reattempt working okay and the error not being replicable.

[aldeed]

Agree it's unlikely but unless you can reliably reproduce the issue it will be difficult to figure out what is really happening.