The elastic-package test failure criteria include a check for a non-present error.message field to indicate that there has not been a pipeline failure during pipeline processing. This use is at odds with the documented semantics of the field.

For error in general

These fields can represent errors of any kind.

Use them for errors that happen while fetching events or in cases where the event itself contains an error.

and for the specific field

Error message.

Together there indicate that the field should be available for use by data sources to include source-specific error states for events.

This is currently not possible because a data stream that uses error.message to hold a data stream-specific error state would be identified as an ingest/processing failure by elastic-package.

The event.kind field does support marking pipeline failures with the "pipeline_error" value. So it is possible to distinguish pipeline failures from other uses of error.message, but this is currently brittle as the pipeline failure event kind is not automatic while setting error.message is.

In order for error.message to be fully open to use in its documented semantics, elastic-package would need to not rely on its state to determine whether pipeline failure has occurred, and if event.kind is used to signal pipeline failure, that pipelines all set that field correctly in the case of a pipeline failure.