Dashboard yaxis assume floats

[zorkian]

Dashboard yaxis assume floats

[samanthadrago]

👋 from a Datadog engineer on the team which owns this part of the API. It's not ideal, but there are a few places in the timeboard/screenboard APIs where we return strings when floats or ints would make more sense. Fixing this will require a new version of the endpoint so it's not planned for the near term, but we've got it on the backlog to include with future work we have planned for dashboards. Thanks for bringing this to our attention!

[robinbowes]

Almost one year since first raised...

Are we any nearer a workaround or fix?

(I arrived here from https://github.com/terraform-providers/terraform-provider-datadog/issues/19 )

[iddl]

Hey everyone, I'm an engineer in the dashboards team. We've been at work on the resolution for this issue.

This specific occurrence is limited in scope since it's unusual for us to change the type of a field, we do not foresee further instances of this happening in the future. More importantly, we're taking steps to guard against this type of occurrences as we 1. add type validation on every submitted field, which has been the standard for newer endpoints 2. clean up invalid occurrences in our data.

This process will take a while since it's likely users are still submitting invalid definitions through api, hence we need to have a grace period as we get in touch with everyone. You should see no more instances of this bug after the operation is complete. In the meantime we suggest you remove min / max fields if they are set to 'auto', just like @yfronto did. Your dashboards will be unaffected by this change.

Thanks everyone for raising the issue.

[zorkian]

Ah interesting. It makes me a bit sad to think about making this a string and have the user be responsible to parse it. Is that the only way?

Really, it's unfortunate that Datadog allows a value that's already the default to be explicitly set to the default.

Hard to say the right approach here:

Option 1

• Change to strings and make everyone sad

Option 2

• Leave the struct as-is
• Have a custom UnmarshalJSON with a temp struct of strings
• Evaluate if strings are nil or equal to "auto", and only set Yaxis values if not

Option 3

• Similar to Option 2, but add some bools to the struct to indicate a IsAuto property

Option 1 makes everyone sad. Option 2 will cause additions of "auto" in the UI to not propagate in (in the Terraform provider, for example). Option 3 breaks parity with the JSON that the API supports, but it does allow the "auto" value to propagate both ways. I suppose there could be an Option 4 that is use custom types for Min and Max that are made of a float and an "auto" bool.

[ojongerius]

I'm leaning towards Option 4. @yfronto / @zorkian what are your thoughts?

@yfronto just checking; this never worked as expected, did it?

I put together a quick PR for Option 4.

[zorkian]

I need to improve my GH notification filtering. I see PRs but I guess not comments very quickly. :(

Anyway, I think Option 4 is probably the best if we can make it work with the accessor generation stuff. And possibly also a sad email to Datadog saying that this kind of thing, while valid in JSON, makes dealing with it in typed languages kind of hard.

@ojongerius see #104. I had a chance to spend a few minutes on this today, but the problem is that there needs to be some exclusivity to the Auto *bool and the Value *float64 (we want setting one to clobber the other). It might be doable by using struct field tags in the declaration of OptionalFloat64 and having gen-accessors.go use reflect to find the tags and generate special accessors, but that seems messy.

My workaround has been to have someone manually go through each dashboard in the UI and remove the "auto" setting manually, but the failure condition is still there.

[ojongerius]

@robinbowes sorry mate, still waiting for someone to volunteer time to fix this one.

Consider setting a bounty if you feel a strong need to get this fixed.

[robinbowes]

@samanthadrago Did this issue make it off your backlog yet?

@ojongerius I'd dig in and have a go myself if I thought I could.

[samanthadrago]

@robinbowes I'm no longer on that team but let me ping someone who is and see if they can weigh in!

[robinbowes]

@samanthadrago Thanks - much appreciated.

[robinbowes]

Hi Ivan,

Thanks for the update.

Can you possibly let us know when this issue is fixed?

R.

[nyanshak]

I believe #167 has addressed this issue. Feel free to reopen if that's not the case.