Loopback-next: patch put date field which is null

[ringodotnl]

Description / Steps to reproduce / Feature proposal

Trying to patch / put a Date field with content null.

Current Behavior

Returns 422 and error code from server is: message: "should be string"

Expected Behavior

Succesfull do the save (or with some property type like allownull? )

[vvdwivedi]

Is this a required field in your model?

[ringodotnl]

Is this a required field in your model?

No

In the model it's defined as:

  @property({
    type: 'date',
  })
  premium_enddate?: Date;

[dhmlau]

@bajtos @jannyHou, is it related to the Partial update (PATCH) over REST issue?

[bajtos]

@ringodotnl please create a small application we can use to reproduce the problem, see our bug reporting instructions. For example, you can modify the Todo application and add a date property to the Todo model.

Then show us the HTTP request you are making: the URL and the full request body.

An automated test that fails against current LoopBack version would be even better, see Todo acceptance tests.

is it related to the Partial update (PATCH) over REST issue?

I cannot tell yet.

[gordancso]

Not sure if this issue still persisted.. a simple workaround is adding nullable attribute in prorperty decorator.

@property({
  type: 'string',
  default: null, 
  nullable: true
})
errorCode: string;

[ringodotnl]

@gordancso thank you, I tried that but still getting a validation_failed code:
The 'message' is "should be string"

It's defined in the model as:

 @property({
    type: 'string',
    default: null,
    nullable: true,
  })
  premium_enddate: string;

(When changing type to a Date, the message is still "should be string")

[gordancso]

@ringodotnl For my side, PATCH actions with null values are working as expected. But for POST, I got an issue of validation error as your and reported in Issue #2626. Would be nice if you can take a look at the potential cause of such validation error.

[marioestradarosa]

Under the hood for any method in the controller where the @requestBody is present, the parser will invoke validateRequestBody which makes use of ajv library to validate the schema (open Api from model spec) agains the JSON object being passed over the body.

It is not possible with the current implementation to skip the validation of a string property in the model with a null value in the body and according to AJV it would be a bad practice thought.

So, I have tested different scenarios and I would probably go for the removal of properties from the client application that contains null values, that way you won't send it over to the API and your validations will not be affected. More over, as the property is ? in your model, it won't hurt either.

Lastly, if we find this scenario so recurrent, we might opt to change the parser.ts to grab a property such as validateSchema from the @requestBody decorator and pass it over to the final validateRequestBody in the AJV.options object , that way we could potentially say to AJV , please don't validate this schema.

In your model, you might have:

 @property({
    type: 'string',
    required: false,
  })
  theDate?: Date;

The required:false is only telling AJV schema validator not to raise any error if that property is missing. theDate? is just telling typescript that object property is optional (_two different things)_.

[ringodotnl]

@marioestradarosa thank you, is there any who can change/fix this ?

[gopalakrishnan-subramani]

https://github.com/strongloop/loopback-next/issues/2626

refer raymondfeng , it solved our problem.

@model()
  class Product {

    @property({required: false, jsonSchema: {nullable: true}})
    description?: string;


    constructor(data: Partial<Product>) {
      Object.assign(this, data);
    }
  }

[ceefour]

I also get this error.

  @property({
    type: 'number',
    required: false,
  })
  noaaTsunamiId?: number;

{
    "error": {
        "statusCode": 422,
        "name": "UnprocessableEntityError",
        "message": "The request body is invalid. See error object `details` property for more info.",
        "code": "VALIDATION_FAILED",
        "details": [
            {
                "path": ".noaaTsunamiId",
                "code": "type",
                "message": "should be number",
                "info": {
                    "type": "number"
                }
            },
            {
                "path": "",
                "code": "not",
                "message": "should NOT be valid",
                "info": {}
            }
        ]
    }
}

Adding jsonSchema: {nullable: true}, as @gopalakrishnan-subramani / @raymondfeng suggested did work as workaround. However I do think behavior should be consistent for all POST/PUT/PATCH.
If required=false + jsonSchema.nullable=true must be used, then behavior must be clearly defined and explicitly stated in the docs.

Note: The other error message is confusing, I think it's another bug but I don't know yet where it came: (maybe https://github.com/strongloop/loopback-next/issues/3645#issuecomment-527582987 ? ). Update: This error is due to POST-ing with id field. I think the error message needs to be improved.

            {
                "path": "",
                "code": "not",
                "message": "should NOT be valid",
                "info": {}
            }

[zzhenryquezz]

Some simlilar error happen with me too when trying to make a filter in url

/entity?filter[where][deleted_at][eq]=null

it was return "Invalid date: null"

The problem happen was because the null in the filter url was a string and not a realy null, so i have to do a workarround to set the null in the code of serve.

[ringodotnl]

For now jsonSchema: {nullable: true} works well.

Closing this.

[fabripeco]

Please add some documentation https://loopback.io/doc/en/lb4/Model.html It's a common issue I think (PATCH via REST API to null some values). Please refer also to how to null to a relation (belongsTo for example).
I resolved with:

@belongsTo(() => ProductType, {name: 'productType'}, {name: 'unit_type_id', jsonSchema: {nullable: true}, })
 unitTypeId?: number;

Thank you

[odykyi]

@fabripeco works for me!