Conversation
internal/fields/validate.go
Outdated
| ) | ||
|
|
||
| // EPF - Elastic Package Fields [validation] | ||
| const ArrayOfObjectsErrorCode = "EPF00001" |
There was a problem hiding this comment.
@mrodm do we have a place where we are already defining Elastic Package errors?
There was a problem hiding this comment.
Currently, there is no definition of errors in Elastic Package. Until now, it was just getting the errors from package-spec validate method and return the errors filtered (if any).
Should this be added into a new internal/errors package ? Or maybe another naming to not have collisions with standard errors package (e.g. validationerrors? I don't like neither too much this).
internal/fields/validate.go
Outdated
| ) | ||
|
|
||
| // EPF - Elastic Package Fields [validation] | ||
| const ArrayOfObjectsErrorCode = "EPF00001" |
There was a problem hiding this comment.
Currently, there is no definition of errors in Elastic Package. Until now, it was just getting the errors from package-spec validate method and return the errors filtered (if any).
Should this be added into a new internal/errors package ? Or maybe another naming to not have collisions with standard errors package (e.g. validationerrors? I don't like neither too much this).
internal/fields/validate.go
Outdated
| } | ||
| errs := v.validateMapElement(key, common.MapStr(val), doc) | ||
| if definition.Type == "group" { | ||
| errs = append(errs, arrayOfObjectsErr) |
There was a problem hiding this comment.
I don't think these errors could be filtered as it is the code.
The methods that get the errors and filter are just for the errors from package-spec. This is in internal/validation package. For instance
There was a problem hiding this comment.
You are right, this would need to be filtered at the moment of testing the package. This makes me wonder if this validation errors filtering fits here, or if this should be configured in tests. What do you think?
I could continue without making this filterable by now. It would only affect packages using spec v3.
|
/test |
💚 Build Succeeded
History
cc @jsoriano |
We added some additional validations for subobjects and arrays of objects in #1498, #1489 and related PRs. These validations only apply to packages with spec starting on 3.0.1. These validations rely on the structure of documents. With the adoption of features like `subobjects: false` or synthetic source the structure is lost, and exceptions based on spec version are not working, so the tests fail for cases where they should not for versions of the spec older than 3.0.1. This happens for example in the `dns` data stream of the `network_traffic` package when LogsDB is enabled.
Add validation for arrays of objects, considering them as valid when they are inside
nestedorgroup.When
groupis used, a filterable error is given, mentioning thatnestedshould be used instead on this case.Fix #1488