## TL;DR
Exit code 1641 is success: the installer finished and started a reboot itself. An agent that treats any non-zero code as failure will abort the wave at exactly the moment a host succeeded and is rebooting. Teach the agent the installer exit code table - 0 and 1641 and 3010 are success family codes with different reboot meanings - and make its next action depend on the meaning: for 1641, wait for the host to reboot and verify, then continue the wave plan for that host after it returns.

```text
agent misread exit code 1641 as failure and aborted the rest of the wave
```

## Use this when
- Wave logs show a host install ending with 1641 followed by the agent marking failure and stopping subsequent items for that host or wave.
- The host actually installed the update and rebooted, contradicting the agent failure record.
- Other success family codes are also being treated as errors by the same logic.

## Not for this skill when
- An installer returned a genuine error code in the 1600 range such as 1603. That is a real fatal install failure and should abort that item.
- The agent already handles 1641 and the abort came from a later step. Trace the actual abort decision before changing code tables.

## Steps
1. Correct the affected wave record first: for every host where 1641 was logged as failure, verify the host real state - update installed, one reboot occurred, services healthy - and amend its record to the true outcome. Hosts the wave abandoned mid-plan need their remaining items rescheduled, because the abort skipped work the plan intended to do. Verify: the affected hosts have true records, and any items skipped by the false abort are identified for rescheduling
2. Audit the agent exit code handling as a table, not a single fix: list every code the agent treats as success, success with reboot required, success with reboot initiated, and failure, and compare it against the Windows Installer and your other installers documented codes. The common success family is 0, 3010, and 1641, but each installer technology in your fleet gets its row checked, including script and package manager exit conventions. Verify: you have a reviewed exit code table per installer type, with the success family codes explicitly classified
3. Implement meaning based handling: on 1641, the agent records install success, expects the host to become unreachable, runs its reboot detection by boot time change, and only then continues with post-reboot steps or the next planned item for that host. On 3010 it records success and schedules the reboot through the normal wave mechanism. Neither code may trigger failure retries or wave aborts. Verify: a test install returning 1641 flows through reboot detection to a success state with no failure entries, and 3010 schedules a reboot rather than failing
4. Protect the wave level logic from single host code confusion: a host item failure should pause that host plan, and only the circuit breaker conditions - rate based, from the wave policy - should stop the whole wave. Review the abort path that turned one misread code into a wave stop and separate item failure from wave failure explicitly. Verify: in testing, a genuine item failure affects only its host, and the wave continues for other hosts
5. Add regression coverage with simulated installer results: feed the agent harness installers returning 0, 1641, 3010, a real error such as 1603, and a code from a non-MSI installer your fleet uses, and assert the agent reaches the correct end state and next action for each. Keep this test set with the agent and run it whenever exit handling or installer tooling changes. Verify: the regression set passes for every code, and the 1641 case specifically asserts wave continuation after host verification

## Why it happens
Installer exit codes are a vocabulary, not a binary. Zero is only the simplest success; Windows Installer also returns 3010 for success where a reboot is required to complete the change, and 1641 for success where the installer already initiated that reboot. An agent written around zero equals success and everything else equals failure will misclassify the two codes that specifically occur on well-behaved installs needing restarts - which is to say, on a large share of real patch installs. The misread then compounds if item failure logic can abort a wave. Correct handling requires the code table per installer, state transitions based on what each code means for the host next, and wave abort logic reserved for genuine systemic signals.

## Variants and edge cases
### Exit code 3010 is mishandled the opposite way
Some agents treat 3010 as plain success and never reboot, leaving the update uncommitted. The table fix must cover both reboot family codes and their different follow-ups.

### Vendor installers return their own success codes
Third-party installers and scripts use custom codes. Document each one in the table from vendor evidence or observed good installs, and default unknown non-zero codes to a human review state rather than an automatic wave abort.

### Agent wraps installers and loses the real code
Wrapper scripts that collapse exit codes destroy the information this handling needs. Fix wrappers to propagate the installer code unchanged before tuning the agent table.

Compatibility: Applies to patch agents driving Windows Installer, setup executables, and scripted installs on Windows fleets, with analogous exit code tables needed for Linux tooling.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_M81p_-pF1BwCSrgtp0jNfQ