[pipeline-error-handling] High-impact ingest error handling gaps in syslog/log pipelines

## Findings

### 1) `system/syslog` pipelines miss `event.kind: pipeline_error` in top-level `on_failure`

**Scope:** free-form system syslog/journald logs (parse failures are expected in production variants).

**Locations and evidence:**
- `packages/system/data_stream/syslog/elasticsearch/ingest_pipeline/default.yml:28-35`
- `packages/system/data_stream/syslog/elasticsearch/ingest_pipeline/log.yml:46-53`
- `packages/system/data_stream/syslog/elasticsearch/ingest_pipeline/journald.yml:36-43`

Each handler sets `error.message` but does not set `event.kind` to `pipeline_error`.

**Why this is wrong:** failed parses are not explicitly classified as pipeline errors, reducing discoverability and operator filtering for failure triage.

**Why it matters:** this is a high-volume free-form source where format drift is normal; missing failure classification makes production parsing failures harder to detect at scale.

**Suggested fix:** in each top-level `on_failure`, add:
- `set: { field: event.kind, value: pipeline_error }`
- keep existing `error.message` assignment.

---

### 2) `vsphere/log` top-level `on_failure` is incomplete (missing `event.kind`)

**Location and evidence:**
- `packages/vsphere/data_stream/log/elasticsearch/ingest_pipeline/default.yml:134-141`

Top-level handler removes `_tmp` and appends `error.message`, but does not set `event.kind: pipeline_error`.

**Context:** same pipeline parses syslog-like free-form messages via multiple grok patterns (`default.yml:11-22`), so parse failures are realistic.

**Why it matters:** failures are less reliably identifiable as pipeline errors in operator workflows.

**Suggested fix:** add `set event.kind = pipeline_error` in top-level `on_failure`.

---

### 3) `sonicwall_firewall` exposes `preserve_original_event`, but failure path ignores user setting

**Manifest evidence (user-visible setting):**
- `packages/sonicwall_firewall/manifest.yml:56-63`

**Failure handler evidence:**
- `packages/sonicwall_firewall/data_stream/log/elasticsearch/ingest_pipeline/default.yml:1419-1434`

Top-level `on_failure` unconditionally appends `tags: preserve_original_event` (`lines 1430-1433`) instead of checking whether the user enabled preserve behavior.

**Why this is wrong:** failure-path retention behavior is not tied to the advertised toggle.

**Why it matters:** on parse failure in real syslog feeds, raw-message retention behavior can diverge from operator intent/compliance expectations.

**Suggested fix:** gate failure-path preserve behavior on tag presence (for example, only append/retain when preserve is already enabled by user configuration), rather than forcing it unconditionally.

## Scan summary

- Pipelines scanned: **1659**
- Missing `on_failure`: **208**
- Incomplete `on_failure` (missing `event.kind` and/or `error.message`): **212**
- `preserve_original_event` packages reviewed from scan: **7**

This report focuses only on high-impact, operator-facing cases rather than enumerating all gaps.

## Suggested Actions

- [ ] Add `event.kind: pipeline_error` to `system/syslog` top-level failure handlers (`default`, `log`, `journald`).
- [ ] Add `event.kind: pipeline_error` to `vsphere/log` top-level failure handler.
- [ ] Make `sonicwall_firewall` failure-path preserve behavior conditional on user-configured preserve intent.

> [!NOTE]
>
> 🔒 Integrity filtering filtered 21 items
>
> Integrity filtering activated and filtered the following items during workflow execution.
> This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.
>
> - issue:#unknown (`search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#18014 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#18009 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#18004 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#18003 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#18001 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#17997 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#17996 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#17995 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#17994 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#17993 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#17992 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#17991 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#17990 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#17989 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - issue:elastic/integrations#17987 (`list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
> - ... and 5 more items
>
>

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Sweeper: Pipeline Error Handler Compliance](https://github.com/elastic/integrations/actions/runs/23533491085)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
> - [x] expires on Apr 1, 2026, 9:31 AM UTC