## TL;DR
3010 (ERROR_SUCCESS_REBOOT_REQUIRED) is a success code wearing a scary number: the update installed and a reboot is needed to complete it. Agent logic must map it explicitly: record the host as installed-pending-reboot, schedule or perform the reboot in the wave reboot phase, verify after reboot, and only then mark final success. The bug is usually a success test written as exit code equals 0, or a generic non-zero-is-failure rule in the executor.

```text
agent failed to handle update exit code 3010 and restarted the wave
```

## Use this when
- Wave logs show 3010 treated as an error, a failure, or an unhandled code that aborts the run.
- Updates are re-offered or the wave restarts from the top after installs that actually succeeded.
- The same agent handles code 0 correctly, isolating the problem to its code table.

## Not for this skill when
- The installer returned a genuine failure code in the 1600 series (for example 1603 fatal error). That is a real install failure to diagnose, not a mapping issue.
- The host rebooted but the update is not present afterwards. That is a rollback, which post-reboot verification should catch as a failure on its own evidence.

## Steps
1. Find the agent exit-code handling and list which codes it treats as success, failure, and unhandled. Verify: 3010 (and its sibling 1641) are absent or misclassified in the current table
2. Add explicit mappings: 0 success; 3010 success-pending-reboot; 1641 success-reboot-initiated; documented failure codes as failures; anything else as unknown requiring inspection, never silent success. Verify: the mapping table is in config or code with each code named
3. Wire the pending-reboot state into the wave flow: hosts in that state join the reboot phase and get a post-reboot verification before final status. Verify: a test host returning 3010 is routed correctly end to end
4. Make the executor stop the wave only for defined fatal conditions, not for any single host non-zero code. Verify: one host odd code no longer restarts a multi-host wave in a test
5. Back-check the previous wave records for 3010 hosts mislabeled as failures and correct their status from host evidence. Verify: corrected records match the hosts actual installed state

## Variant phrasings
### exit code 3010 reboot required agent treats as failure
The main phrasing.
### ERROR_SUCCESS_REBOOT_REQUIRED wave restarted fix mapping
The symbolic-name phrasing.
### installer exit code table 0 3010 1641 1603 agent
The code-table phrasing.

Compatibility: Compatibility: Windows installers (MSI and update packages) returning standard MSI and servicing codes; the state model applies to any platform with reboot-pending outcomes.

## Why it happens
Windows servicing has more than two outcomes, but naive automation is binary: zero good, non-zero bad. 3010 is the most common casualty because it is both extremely frequent (most cumulative updates need a reboot) and numerically adjacent to real errors. The wave-restart symptom comes from a second binary assumption, that an unexpected code must mean the run state is unsafe to continue, when the correct response is a per-host state transition.

## Edge cases / pitfalls
- Linux has analogues: package tools and firmware updaters return reboot-required signals that deserve the same explicit state, not a failure label.
- Do not map unknown codes to success to make the table complete; unknown must stay a visible, inspectable state.
- Post-reboot verification is what makes the 3010 mapping safe: without it, a rollback after reboot would still be counted as success.

## Provenance

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