API breaking change: coding_rate

TTN Network and Services The Things Stack v3
1

Today I noticed that the coding_rate field in the uplink message json moved. This is a breaking change for people relying on the coding_rate field.

Before:

{
   "end_device_ids":{
      ...
   },
   "received_at":"2022-06-22T13:31:22.584316406Z",
   "uplink_message":{
      ...,
      "settings":{
         "data_rate":{
            "lora":{
               "bandwidth":125000,
               "spreading_factor":7
            }
         },
         "coding_rate":"4/5",
         ...
      },
      ...
   }
}

Currently:

{
   "end_device_ids":{
      ...
   },
   "received_at":"2022-10-10T13:52:03.132322789Z",
   "uplink_message":{
      ...
      "settings":{
         "data_rate":{
            "lora":{
               "bandwidth":125000,
               "spreading_factor":8,
               "coding_rate":"4/5"
            }
         },
         ...
      },
      ...
   }
}
1 Like
2

This was briefly mentioned in

The example at
https://www.thethingsindustries.com/docs/reference/data-formats/#uplink-messages
is now slightly out-of-date. Sent a message about that.

3

Thanks for the issue @jpmeijers. This change breaks our compatibility commitment and should not have been removed.
We are filing a fix which will revert this v3.22.1.
Apologies for the delayed response here.

1 Like
4

Will the fix simply move the field back to its original location? Or will it be duplicated somehow?

5

I second this query, having just pushed a code fix reflecting the move of the coding_rate :wink:

1 Like
6

“fixing” this now is a little pointless, as the API is already broken, and we were already forced to update our API clients.

This however is a good example for TTI of a simple change breaking things.

I’m also wondering why this break wasn’t detected by TTI after the update. My webhooks started failing, so this should have shown up on TTI’s metrics.

7

We will duplicate the fields for now and add a deprecation notice on TxSettings.CodingRate.

“fixing” this now is a little pointless, as the API is already broken, and we were already forced to update our API clients.
This however is a good example for TTI of a simple change breaking things.

Users were quick enough in this instance to fix clients.
We will still reinstate the field and follow our deprecation process. That’s a reminder for us in the future not miss this and keep our compatibility commitment.

I’m also wondering why this break wasn’t detected by TTI after the update. My webhooks started failing, so this should have shown up on TTI’s metrics.

Screenshot 2022-10-13 at 08.29.23
Screenshot 2022-10-13 at 08.29.231844Ă—610 150 KB

Our metrics did not pick up a huge drop. TTS CE traffic is so massive these days that small drops are difficult to track without our alerting system constantly blowing up.

Items like this shouldn’t be tracked by metrics; I have some solutions for that which I’ll look into with the team.

3 Likes