ditto icon indicating copy to clipboard operation
ditto copied to clipboard

ImplicitThingCreation incorrect response when the thing already exists

Open desislava-marinova opened this issue 2 years ago • 6 comments

ImplicitThingCreation mapper is configured as follows:

"implicitEdgeThingCreation": {
      "mappingEngine": "ImplicitThingCreation",
      "options": {
        "thing": {
          "thingId": "{{ header:device_id }}",
          "_copyPolicyFrom": "{{ header:gateway_id }}",
          "attributes": {
            "Info": {
              "gatewayId": "{{ header:gateway_id }}"
            }
          }
        }
      },
      "incomingConditions": {
        "behindGateway": "fn:filter(header:gateway_id, 'exists')"
      }
    }

According to the ImplicitThingCreation mapper configuration

commandHeaders (optional, default: {"If-None-Match": "*"}): The Ditto headers to use for constructing the “create thing” command for creating the twin and to use for creating errors.

The expectation is that the mapper should not fail with error creating policy but should result in

{
    "status": 412,
    "error": "things:precondition.failed",
    ....
}

Currently, the mapper fails with an error with status 400

{
  "correlationId": "ebdd03fd-dc20-487c-af42-91ac5628624a",
  "timestamp": "2023-07-27T11:37:46.994466Z",
  "category": "response",
  "type": "dispatched",
  "level": "failure",
  "message": "Response was not successful. This may be the case for when a thing could not be found or the authorization subject of the consuming source was not allowed to write a thing. - Message headers: [ditto-origin=e850970b-cac5-436a-bbe8-729684ce89e4, if-none-match=*, ditto-inbound-payload-mapper=implicitEdgeThingCreation, ditto-originator=ditto:ditto, response-required=false, correlation-id=ebdd03fd-dc20-487c-af42-91ac5628624a, ditto-auth-context={\"type\":\"pre-authenticated-connection\",\"subjects\":[\"ditto:ditto\"]}, ditto-entity-id=thing:namespace:my-thing, allow-policy-lockout=true, requested-acks=[]] - Message payload: {\"type\":\"things.responses:errorResponse\",\"status\":400,\"thingId\":\"namespace:my-thing\",\"payload\":{\"status\":400,\"error\":\"things:thing.notcreatable\",\"message\":\"The Thing with ID 'namespace:my-thing' could not be created because creation of its implicit Policy ID 'namespace:my-thing' failed.\",\"description\":\"If you want to use an existing Policy, specify it as 'policyId' in the Thing JSON you create.\"}}",
  "address": "_responses",
  "entityType": "thing",
  "entityId": "namespace:my-thing"
}

desislava-marinova avatar Jul 24 '23 13:07 desislava-marinova

Hi @desislava-marinova I would have expected that using the header If-None-Match: * should have worked.

So I would see that as bug, if it is tried to create the inline or copied policy and therefore fails completely.

thjaeckle avatar Jul 24 '23 18:07 thjaeckle

According to the ImplicitThingCreation mapper configuration

commandHeaders (optional, default: {"If-None-Match": "*"}): The Ditto headers to use for constructing the “create thing” command for creating the twin and to use for creating errors.

@thjaeckle, does it mean that without adding explicitly commandHeaders in the mapper configuration, the mapper should not fail with error creating policy but should result in

{
    "status": 412,
    "error": "things:precondition.failed",
    ....
}

desislava-marinova avatar Jul 26 '23 11:07 desislava-marinova

Yes, I would also think/assume so ..

thjaeckle avatar Jul 26 '23 12:07 thjaeckle

Thanks @thjaeckle Should I create a new bug ticket for that misbehavior, or could this be reused?

desislava-marinova avatar Jul 26 '23 12:07 desislava-marinova

I would reuse this one and rephrase accordingly :)

thjaeckle avatar Jul 26 '23 12:07 thjaeckle

The description and title were updated.

desislava-marinova avatar Jul 27 '23 11:07 desislava-marinova