decimal field with min or max, resolveInput triggers error

[Thinkscape]

Steps

1. Have a list with a decimal field

list({
  fields: {
    lineAmount: decimal({
      validation: { isRequired: false, min: "0.0" },
      defaultValue: "0",
      precision: 10,
      scale: 2,
    }),
});

2. Have a list resolveInput that changes the value:

list({
  hooks: {
    resolveInput: ({ resolvedData }) {
      return {
        ...resolvedData,
        lineItem: 666
      };
   }
});

3. Send a create or update against the list

Expected

Items gets created/updated successfully (with the lineItem: 666 value)

Actual

An error occured while running "validateInput".
  - ListName.lineAmount.hooks.validateInput: val.lessThan is not a function

Workarounds

• Moving the logic to beforeOperation and mutating the resolvedData instance works around the problem.
• Adding max to field config doesn't help.
• Removing min max validation from field config works around it (but disables validation)
• Returning number or string from resolveInput for the decimal field doesn't seem to change anything.

[borisno2]

This is most likely due to the Decimal validation expecting to be passed a decimal (.lessThan is not available on number or string).

I am assuming if you passed a Decimal into resolveInput validation would succeed for example:

list({
  hooks: {
    resolveInput: ({ resolvedData }) {
      return {
        ...resolvedData,
        lineItem: new Decimal(666)
      };
   }
});

One possible fix in Keystone, to support passing in a number or string into resolve input, would be to parse val in the decimal validation.

[Thinkscape]

Ah! I shall try that.
If that's the case, then the confusion came from the fact, that beforeOperation is perfectly fine with passing number values, and it casts (wraps) them with Decimal 🤔

[dcousens]

Fixed by #9262

[dcousens]

beforeOperation is perfectly fine with passing number values

What do you mean by this? What is passing a number in this situation?
I think our GraphQL resolvers should be only passing a Decimal type through, but maybe Prisma is liberal in what it accepts?

Probably easiest to follow Prisma for this