Wrong deduplication Id in HTTP Push?

[krystof018]

Hello, I found strange and for me also unwanted behaviour which I suspect to be and error. When I send downlink and save the returned id from the request, I check for HTTP Push that has the acknowledged parameter as It always refers resolution of downlink that was in queue. Then I check queueItemId and mark the packet I sent as either resolved or failed in my application. For some reason this sometimes didn’t work and I now noticed why. I also check for deduplicationId and only process the first occurrence of one. For some reason when the LoRa device sends uplink in between the sending of downlink and receiving ack, the deduplication id in the HTTP Push request is the same for the uplink and the resolution request.

See this example:

I receive this message upon scheduling downlink to the queue

{
   "downlinkId":2452697141,
   "time":"2023-04-19T05:06:01.870749703+00:00",
   "deviceInfo":{
      ...
   },
   "queueItemId":"242fe516-11fb-4e82-8d3e-dfa718f05107",
   "fCntDown":111,
   "gatewayId":"",
   "txInfo":{
      ...
      },
      "timing":{
         "immediately":{
            
         }
      },
     ...
   }
}

Then the LoRa device sends uplink and I receive this:

{
   "deduplicationId":"45c4ecac-f6d7-4ea5-91a8-8c847aa77496",
   "time":"2023-04-19T05:06:12.002147892+00:00",
   "deviceInfo":{
     ...
   },
   "devAddr":"..",
   "adr":true,
   "dr":5,
   "fCnt":129,
   "fPort":1,
   "confirmed":true,
   "data":"data",
   "rxInfo":[
      {
         ...
      }
   ],
   "txInfo":{
      ...
   }
}

And then I receive this:

{
   "deduplicationId":"45c4ecac-f6d7-4ea5-91a8-8c847aa77496",
   "time":"2023-04-19T05:06:12.003066892+00:00",
   "deviceInfo":{
      "...
   },
   "queueItemId":"242fe516-11fb-4e82-8d3e-dfa718f05107",
   "acknowledged":true,
   "fCntDown":111
}

Why does the last HTTP Push request have the same deduplication Id as the uplink?

[brocaar]

This is because the uplink of that deduplication ID generated two events:

1. An up event containing the data
2. The acknowledgement of the confirmed downlink

That is why you are seeing the same deduplication ID twice, as both events have the same uplink as origin.