You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{
"type": "illegal_state_exception",
"reason": "value source config is invalid; must have either a field context or a script or marked as unwrapped"
}
The problem is that the exception is generated from what is an otherwise invalid ValuesSourceConfig object. E.g. when resolving we identify that there is no script or field, generate an invalid VSConfig, then later at the factory layer check to see if the VSConfig is valid and throw an exception.
Besides being confusing from a code perspective, it also means we don't throw until we've already broadcast the request to the cluster. We should instead fail during parsing because there is no sensible reason to omit both field and script (I don't think?)
Note: There are a few instances (e.g. ParentAggregationBuilder) that use the mutability of VSConfig which may be why we ended up in this situation. But even if we don't fix that part of VSConfig, we can head off these scenarios at the parse layer first.
Hi @ejmiers, sorry for the delay! Been traveling for work lately and my inbox has been a mess.
You can certainly work on this issue if you like! It shouldn't be too difficult, but also not the easiest first issue either. The actual change is relatively small but it requires knowing how our static json parsers work which can be a little tricky.
If you'd like to work on it I'm happy to help. You might also want to skim through the list of issues tagged with help needed or good first issue which have been specifically called out as items which are good for first time contributors
Today if you specify an aggregation with no
field
orscript
like so:We throw an exception:
The problem is that the exception is generated from what is an otherwise invalid ValuesSourceConfig object. E.g. when resolving we identify that there is no script or field, generate an invalid VSConfig, then later at the factory layer check to see if the VSConfig is valid and throw an exception.
Besides being confusing from a code perspective, it also means we don't throw until we've already broadcast the request to the cluster. We should instead fail during parsing because there is no sensible reason to omit both field and script (I don't think?)
Note: There are a few instances (e.g.
ParentAggregationBuilder
) that use the mutability of VSConfig which may be why we ended up in this situation. But even if we don't fix that part of VSConfig, we can head off these scenarios at the parse layer first.Related to #42949
The text was updated successfully, but these errors were encountered: