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.
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.
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.
Inconsistent values for mac_settings
enum fields
All values should be returned in the same format (raw/string)
v3.7.0-rc2
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
Yes, but need input from @rvolosatovs @johanstokking @htdvisser
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
Most helpful comment
Great one for V4