UpdateTwinWithLiveResponse mapper consuming response so that client runs into timeout

[thomas-fries-keen]

Hi @thjaeckle,

we are adopting the use of live channel for HTTP get requests of features. We also want to update the latest twin state with the live response.

In https://eclipse.dev/ditto/2021-12-22-live-channel-condition.html there was mentioned, that the UpdateTwinWithLiveResponse mapper is creating a merge command in addition to the live response. So we were hoping that the twin gets updated on the fly while a client is using the live channel. Unfortunately, it seems that the mapper is transforming the response into a merge command - thus the original response message is not forwarded to the client.

So in case of a timeout != 0, the client will run into a timeout. When we remove the mapper in the connection, the client gets the response as expected.

The workflow for the client gets a bit uncomfortable then. You need first to do a call with channel=live&timeout=0 to trigger the update of the twin and then a second call with channel=twinis required to finally get the latest value from the device.

• are we doing something wrong?
• would it be possible for this special mapper to create the merge while still preserving the live response?

Thanks for the feedback, Thomas

[thjaeckle]

How is your connection configured?
I think the UpdateTwinWithLiveResponse mapper should in such a use case be added as an additional payload mapper, leaving the Ditto one intact (to answer the original request normally).

[thomas-fries-keen]

Hi again, thanks for the quick response.

here is the connection:

{
  "id": "my-kafka",
  "name": "my-kafka",
  "connectionType": "kafka",
  "connectionStatus": "open",
  "uri": "tcp://somehost:9092",
  "sources": [
    {
      "addresses": [
        "ditto.response.in"
      ],
      "consumerCount": 1,
      "qos": 1,
      "authorizationContext": [
        "integration:kafka"
      ],
      "headerMapping": {},
      "payloadMapping": [
        "liveTwinUpdate"
      ],
      "replyTarget": {
        "address": "",
        "headerMapping": {},
        "expectedResponseTypes": [
          "response",
          "error"
        ],
        "enabled": false
      }
    }
  ],
  "targets": [
    {
      "address": "someservice.command.in",
      "topics": [
        "_/_/things/live/messages",
        "_/_/things/live/commands"
      ],
      "authorizationContext": [
        "integration:kafka"
      ],
      "headerMapping": {}
    }
  ],
  "clientCount": 1,
  "failoverEnabled": true,
  "validateCertificates": false,
  "processorPoolSize": 1,
  "specificConfig": {
    "saslMechanism": "plain",
    "bootstrapServers": "somehost:9092"
  },
  "mappingDefinitions": {
    "liveTwinUpdate": {
      "mappingEngine": "UpdateTwinWithLiveResponse",
      "options": {
        "dittoHeadersForMerge": {
          "response-required": false
        }
      }
    }
  },
  "tags": []
}

Indeed, only the UpdateTwinWithLiveResponse mapper was active. I tried to add the Ditto mapper -> then we get the response, but the merge is not executed :-(

[thomas-fries-keen]

Hi @thjaeckle,

It works now! But the order of the mappers matters. I tried:

      "payloadMapping": [
        "Ditto",
        "liveTwinUpdate"
      ],

Like described in this example. And this apparently works as expected.

I'm sure I tried the opposite order before where it was not working

Thank you for the hint

Thomas

[thjaeckle]

Thanks for the feedback @thomas-fries-keen
This is a strange requirement - but may be really needed in the order 🤷