fix: Add required fields to the signature of experimental/to

[Marwes]

The documentation implies that these fields are mandatory to call this function and looking at the implementation it will indeed error if they are missing. Changing this is still technically a breaking change so maybe we want some caution before merging this? (#4773 could perhaps be used to allow an incremental rollout, or I could run this through the query log analyzer I made for #4776)

[wolffcm]

Incidentally, I wrote the experimental.to code. It just seems like the user would get a different error if _measurement or _time was missing? This seems totally fine to me.

If you are still cautious, you might try out this change in remocal and verify that the new behavior isn't any worse.

[Marwes]

Yeah, in theory it would just be a compiletime error instead of a runtime one. But there may be some weirdness due to type inference changing or perhaps the current runtime error doesn't fire for a script as the execution never reaches that point

[wolffcm]

@Marwes

But there may be some weirdness due to type inference changing or perhaps the current runtime error doesn't fire for a script as the execution never reaches that point

I'm not sure what you mean here. Are you thinking of a particular case?

It does seem that a query that sends no data to experimental.to would succeed today. It could be that users use to as a way to log infrequent error conditions in their application. However, this mechanism would have never succeeded for them, if _measurement and _time were missing, as both fields are truly required to write data to InfluxDB.

We developed experimental.to as a way to enable the alerting framework, which uses Flux code generated by the UI. My sense is that almost all uses of experimental.to are for this. I think if you were to run some of these generated queries through type inference and they continue to succeed, then we are probably pretty safe here.

[Marwes]

I'm not sure what you mean here. Are you thinking of a particular case?

The case of no data is one, another could be just a random statement that never gets executued.

if false then
    array.from(rows: [{}]) |> experimental.to()

which would now fail at compile time.

We developed experimental.to as a way to enable the alerting framework, which uses Flux code generated by the UI. My sense is that almost all uses of experimental.to are for this. I think if you were to run some of these generated queries through type inference and they continue to succeed, then we are probably pretty safe here.

Where do I find these?

[github-actions]

This PR has had no recent activity and will be closed soon.