Lorawan-stack: Inconsistent enum rendering in JSON responses

Created on 29 Mar 2020  ·  5Comments  ·  Source: TheThingsNetwork/lorawan-stack

Summary

References: https://github.com/TheThingsNetwork/lorawan-stack/issues/2047

Values returned by NS for enums within the mac_settings field are inconsistent. Some for some NS returns raw values and for others a string representation is returned.

Steps to Reproduce

  1. Set mac_settings.rx1_delay.value
// request
{
   "end_device":{
      "mac_settings":{
         "rx1_delay":{
            "value":5 // or 'RX_DELAY_5'
         }
      }
   },
   "field_mask":{
      "paths":[
         "mac_settings.rx1_delay.value",
      ]
   }
}

// response
{
   ...
   "mac_settings":{
      "rx1_delay":{
         "value":5
      },
   }
}

// Note, regardless of what you send as the value for mac_settings.rx1_delay.value you always get the raw enum value.
  1. Set mac_settings.ping_slot_periodicity.value
// request

{
   "end_device":{
      "mac_settings":{
         "ping_slot_periodicity":{
            "value": 1 // or 'PING_EVERY_2S'
         }
      }
   },
   "field_mask":{
      "paths":[
         "mac_settings.ping_slot_periodicity.value"
      ]
   }
}

// response

{
   "mac_settings":{
      "ping_slot_periodicity":{
         "value":"PING_EVERY_2S"
      }
   }
}

// Again, regardless of what you send you always get the string representation of the value.

What do you see now?

Inconsistent values for mac_settings enum fields

What do you want to see instead?

All values should be returned in the same format (raw/string)

Environment

v3.7.0-rc2

How do you propose to implement this?

I guess first we have to agree on the format. Then it is the matter of adjusting https://github.com/TheThingsNetwork/lorawan-stack/blob/master/api/lorawan.proto and https://github.com/TheThingsNetwork/lorawan-stack/blob/master/pkg/ttnpb/lorawan.go

Can you do this yourself and submit a Pull Request?

Yes, but need input from @rvolosatovs @johanstokking @htdvisser

bummajor compaapi

Most helpful comment

Great one for V4

All 5 comments

What input is required from us (@rvolosatovs @johanstokking @htdvisser)? Is this issue missing a discussion label?

FTR, I think it depends on what fields we're talking about, but for LoRaWAN-specific MAC stuff I think we should use just the number, since that aligns with the spec (Ping slot periodicity of PING_EVERY_2S is not defined in the spec, however the one of 1 is)

This is unfortunately not something that we can just change, as it would violate our API compatibility commitment, so this is definitely not something for March.

There are currently indeed multiple ways to render an enum. For instance, MACVersion can be rendered as "MAC_V1_0_2", 3 (both jsonpb-compliant) or as "1.0.2" (with TTN's stringer, not compliant). In the past we've made the mistake of using the third ("1.0.2") when rendering JSON. We shouldn't have done that, but we can't change that anymore without breaking our API.

In order to be as compatible as possible, we do accept all forms in request messages, but what we return can't easily be changed anymore.

In the future (with goproto v2 API) we could perhaps add support for an extension in the Accept header, similar to how Github does this. This extension could then be used to tell the server how enums (and for example zero fields) should be rendered.

closed since we wont fix this

I don't think we should immediately dismiss this as a wontfix. Let's keep it in the backlog and see if we can fix it in the future.

Great one for V4

Was this page helpful?
0 / 5 - 0 ratings

Related issues

w4tsn picture w4tsn  ·  6Comments

ecities picture ecities  ·  5Comments

kschiffer picture kschiffer  ·  7Comments

ecities picture ecities  ·  5Comments

htdvisser picture htdvisser  ·  4Comments