[ES|QL] `BUCKET` definition reports 3rd and 4th args as optional for 4-arg signatures

[drewdaemon]

Elasticsearch Version

main

Installed Plugins

No response

Java Version

bundled

OS Version

n/a

Problem Description

In the definitions for Kibana, BUCKET reports the 3rd and 4th parameters as optional for signatures in which they are actually required.

For example, this one

  {
      "params" : [
        {
          "name" : "field",
          "type" : "date",
          "optional" : false,
          "description" : "Numeric or date expression from which to derive buckets."
        },
        {
          "name" : "buckets",
          "type" : "integer",
          "optional" : false,
          "description" : "Target number of buckets, or desired bucket size if `from` and `to` parameters are omitted."
        },
        {
          "name" : "from",
          "type" : "date",
          "optional" : true,
          "description" : "Start of the range. Can be a number, a date or a date expressed as a string."
        },
        {
          "name" : "to",
          "type" : "keyword",
          "optional" : true,
          "description" : "End of the range. Can be a number, a date or a date expressed as a string."
        }
      ],
      "variadic" : false,
      "returnType" : "date"
    },

This leads to the client-side validation not reporting errors for certain incorrect calls to BUCKET

Steps to Reproduce

Look at the file :)

Logs (if relevant)

No response

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[nik9000]

The markdown table of valid signatures shows it pretty well:

field	buckets	from	to	result
date	date_period			date
date	time_duration			date
date	integer	date	date	date
double	double			double
double	integer	double	double	double
...

But we generate the 3rd and 4th as "optional" because we mark them that way in the annotations. But that aren't optional when they are required. Well, that's a funny thing to say. Let me play with the annotations.

[nik9000]

Another option is for us to drop optional entirely. We spit out all of the signatures we support (ignoring varargs functions and CASE which are too special). If the signature doesn't appear in the list we make for you, it's not valid. If an argument is truly optional in all the ways that matter, we'll have another signature that's the same but shorted. We have to do that as part of our testing.

[drewdaemon]

Actually, this might be a good way to go. Like you say, optional is really just shorthand for another signature.

[drewdaemon]

cc @stratoula

[nik9000]

Actually, this might be a good way to go. Like you say, optional is really just shorthand for another signature.

I think the thing to check is - if you ignore optional altogether, which signatures do you lose? It should be just these. Can you make a diff on your side somehow?

[stratoula]

yes it is good to check if this will work on our side before we do it @drewdaemon but I agree that it makes sense to drop it

[drewdaemon]

I would vote for us to move forward with #133682 and I can put it on my list to do a bit of investigation and report back.

[stratoula]

Agreed