-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Threholds do not roundtrip properly during marshaling #686
Comments
For the reference, field configuration is JSON encoded in the plugin <-> Grafana communication (L108): grafana-plugin-sdk-go/data/arrow.go Lines 87 to 124 in 3e2ff58
As such, unmarshaling has to be done also through JSON, and the grafana-plugin-sdk-go/data/arrow.go Lines 324 to 352 in 3e2ff58
|
What happened:
I am trying to dynamically build some thresholds for a particular field. My thresholds look as follows:
The problem is that if I check the schema in the browser response, I see the that the value for the first threshold is 0, not null or missing.
What you expected to happen:
I expected the first threshold to be rendered as
null
, but it is rendered as a zero value.How to reproduce it (as minimally and precisely as possible):
Try to dynamically build thresholds in the backend, for any field.
Anything else we need to know?:
I think this happens because there is another marshaling round trip happening between the plugin and Grafana itself.
The definition of a threshold is as follows:
grafana-plugin-sdk-go/data/field_config.go
Lines 209 to 214 in 3e2ff58
Notice that the value is not nullable - even if a
null
would be present in JSON (from the plugin to Grafana), there would not be anull
if you convert to a struct and then back to JSON later - unmarshalling would put a zero value in there. This is I hope trivially visible, but the following test also shows this in Go:The solutions don't look too good:
ConfFloat64
null
means that the value should be filled with-Inf
orNaN
. This is not ideal (null
is supposed to be a semantical skip), but I guess it could work ?Value
nullable. This is again not ideal because currently0.0
is currently skipped due toomitempty
. This means that plugins compiled with older versions of the SDK will turn0.0
intonull
during round trip, which is a breaking change.-math.MaxFloat64
for the lower bound instead. It's not really equivalent to having anull
I guess, but it's pretty close.Environment:
v0.161.0
9.5.2
1.20.4
The text was updated successfully, but these errors were encountered: