ParserTestCaseOutputFailures
ParserTestCaseOutputFailures
is a datatype for failures for an output event.
Table: ParserTestCaseOutputFailures
Parameter | Type | Required | Default | Stability | Description |
---|---|---|---|---|---|
Some arguments may be required, as indicated in the Required column. For some fields, this column indicates that a result will always be returned for this column. | |||||
Table last updated: Mar 24, 2025 | |||||
arraysWithGaps | [ArrayWithGap ] | yes | Short-Term | Any arrays with gaps in them. For example, if the fields a[0] and a[2] exist on an event, but not a[1] , we consider the array a to have a gap. This means LogScale will not include the a[2] field when doing array-based searches, since it considers a[0] to be the last element of the array. This is a preview and might change. See ArrayWithGap . | |
assertionFailuresOnFields | [AssertionFailureOnField ] | yes | Long-Term | Any assertion failures on the given output event. Assertion failures can be uniquely identified by the output event index and the field name they operate on. This is a preview and might change. See AssertionFailureOnField . | |
falselyTaggedFields | [string] | yes | Short-Term | Fields where the name begins with `#` even though they aren't taga. In LogScale, field names beginning with `#` are treated specially, and should only be constructed through the tagging mechanism. Fields which do begin with `#`, but aren't proper tags, will be effectively unsearchable. This is a preview and might change. | |
parsingErrors | [string] | yes | Long-Term | Any errors produced by the parser when creating an output event. | |
schemaViolations | [SchemaViolation ] | yes | Short-Term | Returns violations of a schema if a schema has been provided. See SchemaViolation . |