Skip to content

Latest commit

 

History

History
33 lines (27 loc) · 1.61 KB

README.md

File metadata and controls

33 lines (27 loc) · 1.61 KB

Repository to reproduce the issue when using JsonTypeInfo.As.WRAPPER_OBJECT

Description

If WRAPPER_OBJECT is used the correct deserialization depends on attributes order.

  1. See broken-payload - if contact_message is followed by any other attributes values are not deserialized (== null)
  2. See valid-payload - if contact_message is placed as last attribute object is deserialized fully and correctly
  3. If contact_message is defined not as last within the code (or by definition of Order). The resulting json object having miss-placed the later attributes. In my example e.g. conversation_id and contact_id as serialized JSON looks as follows:
{
  "project_id": "project-id",
  "message": {
    "id": "message-id",
    "direction": "direction",
    "contact_message": {
      "text_message": {
        "text": "Body"
      },
      "conversation_id": "conversation-id",
      "contact_id": "contact-id"
    }
  }
}

Assumptions

  • I did some investigation and it seems when we de-serialize the wrapper object and call the io.micronaut.serde.Decoder.finishStructure(boolean) when we are increment remaining depth we only increment by +1 which breaks the objectDecoder logic defined at io/micronaut/serde/support/deserializers/SimpleObjectDeserializer.java:90 as it returns null on decodeKey() which stops the Message object de-serialization.

Resources

The models can be found here

The test to simulate the scenarios here