## TL;DR
The dangerous part is not the parse failure, it is the silence: a parser exception caught by a broad handler turns into an empty approval list, and the planner calmly builds a wave with no critical updates. Parse defensively with a real XML parser (never regex), validate the result against expectations (counts, presence of known critical KBs), and make any parse anomaly a hard, loud failure of the sync, never an empty set.

```text
agent's parser failed on wsus approval xml and skipped critical updates
```

## Use this when
- Wave plans are missing updates that are approved and visible in the WSUS console.
- Logs contain a caught parsing exception that nobody alerted on.
- The problem began after a WSUS upgrade or a very large sync (unusually big XML).

## Not for this skill when
- The updates are not actually approved for the target group. Check WSUS first; the parser may be innocent.
- The XML is fine but the approval logic filters wrong. That is a rules bug, not a parse bug.

## Steps
1. Reproduce with the actual payload: save the raw XML response and run the parser against it offline. Verify: the failing element or malformation is identified in the real data
2. Replace any regex or string-splitting XML handling with a standards-compliant parser and explicit handling for namespaces and unknown elements. Verify: the parser processes the saved payload and older fixtures correctly
3. Add result validation: approval counts per severity compared against the WSUS-reported counts, and a canary check that at least the expected critical KBs are present when WSUS says they are approved. Verify: a mismatch aborts the sync with a validation error
4. Remove broad exception swallowing around parsing: parse errors propagate as sync failures with alerts. Verify: the corrupted fixture now fails loudly in a test
5. Re-run the sync and diff the plan against the WSUS console approvals. Verify: the plan includes the previously skipped critical updates

## Variant phrasings
### wsus approval xml parser skipped critical updates silent
The main phrasing.
### never swallow parse errors empty set patch planning
The design-rule phrasing.
### validate parser output counts canary kb present
The validation phrasing.

Compatibility: Compatibility: WSUS API responses and exported XML; any language XML parser with namespace support.

## Why it happens
WSUS payloads evolve: server updates add elements, huge syncs stress streaming assumptions, and a brittle hand-rolled parser breaks on exactly the runs that matter most (the big Patch Tuesday sync). The silent-skip failure mode is a composition of two common agent sins, fragile parsing plus catch-all error handling, and it is worse than a crash because the output looks like a valid, smaller plan.

## Edge cases / pitfalls
- Streaming parsers have memory virtues but fail differently on truncation; whichever style you use, test with truncated and oversized fixtures, not just well-formed ones.
- A proxy or security appliance that rewrites XML in transit produces malformations no parser update fixes; capture bytes at the client to prove where the corruption enters.
- Keep the last known-good raw payload and parsed result; diffing them against a bad run is the fastest diagnosis.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zSLsDOiLfehSNbYmA43SYA