agent failed by treating reboot pending flag as update failure

Not specified by the original author.

TL;DR

Reboot pending is a success-in-progress state, not a failure flavor. The agent state model must separate install outcome from reboot state: a host can be installed-and-pending-reboot, and its final verdict waits for the post-reboot verification. Fix the classification where the flag is read (the compliance query or the agent status mapping), align the report categories with the model, and make retries skip pending-reboot hosts until they have rebooted and been rechecked.

agent failed by treating reboot pending flag as update failure

Use this when

• Failure counts include hosts that show the update as installed after a manual check and a reboot.
• The agent retries installs on hosts that are simply waiting for their reboot window.
• Failure rate drops to near zero after someone reboots the flagged hosts by hand.

Not for this skill when

• The host needs a reboot because an earlier, different update failed and rolled back to a pending state. Read the per-update state, not just the flag.
• The flag is stale and never clears (a servicing flag bug on the host). That host needs the stale-flag remediation, not just reclassification.

Steps

1. Trace where the agent reads host state and how the reboot-pending flag maps into its outcome enum. Verify: the exact mapping that converts pending into failed is located
2. Change the state model: install outcome (installed, failed, not attempted) tracked separately from reboot state (none, pending, done), with final success requiring installed plus reboot done plus post-reboot verification. Verify: the model is reflected in the tracker schema and the report
3. Update retry logic to exclude installed-pending-reboot hosts from reinstall attempts and route them to the reboot phase. Verify: a test wave performs zero reinstalls on pending hosts
4. Reclassify the current fleet records using host evidence, moving false failures to their true states. Verify: the corrected failure rate is restated in the wave report with a note
5. Add a report check: pending-reboot hosts older than a defined age (for example past their reboot window) escalate as a reboot-scheduling problem, not as patch failures. Verify: aging pending hosts surface under the right problem label

Variant phrasings

reboot pending flag counted as update failure agent state model

The main phrasing.

installed pending reboot separate outcome and reboot state

The modeling phrasing.

false failure rate patch report pending reboot hosts

The reporting phrasing.

Compatibility: Compatibility: Windows hosts (CBS and Windows Update pending flags) and Linux (reboot-required indicators such as the var run reboot-required file on Debian-family).

Why it happens

The bug is a modeling shortcut: one flag read as one verdict. Servicing reality is two-dimensional, because installing and rebooting are separate acts separated by policy and time, especially in fleets where reboots wait for windows. Collapsing the dimensions manufactures failures, and manufactured failures trigger real harm: reinstall attempts on healthy hosts, wasted windows, and a failure metric nobody trusts, which then hides genuine failures in the noise.

Edge cases / pitfalls

• Keep the dimensions separate in every downstream consumer (dashboards, alerts, SLA math), not only in the tracker, or the shortcut reappears in reporting.
• A host can be pending reboot from an update outside the wave; the model should record which update set the flag when that is knowable.
• Post-reboot verification closes the loop: pending is a promise, verification is the proof.

Provenance

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

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

Thread query: agent failed by treating reboot pending flag as update failure

TL;DR: Reboot pending is a success-in-progress state, not a failure flavor. The agent state model must separate install outcome from reboot state: a host can be installed-and-pending-reboot, and its final verdict waits for the post-reboot verification. Fix the classification where the flag is read (the compliance query or the agent status mapping), align the report categories with the model, and make retries skip pending-reboot hosts until they have rebooted and been rechecked.

Not specified by the original author.

TL;DR

A wave is not complete when installs finish; it is complete when hosts have installed, rebooted, and verified healthy after the reboot. Fix the agent completion rule: pending reboot is an open state that keeps the wave in progress, the agent tracks reboots to completion or to an escalation deadline, and the final wave report separates installed-and-verified from installed-awaiting-reboot. Then chase the pending reboot population down with scheduled restarts instead of discovering it at the next wave.

patch agent marked wave complete while half the hosts still showed pending reboot

Use this when

• Wave reports say complete while dashboards or host checks show many wave hosts still pending reboot days later.
• The next wave finds previous updates still not committed on the same hosts.
• Hosts are servers or shared machines whose reboots nobody owns after the agent finishes installing.

Not for this skill when

• Hosts failed the install and need repair. They are not pending reboot; they belong in the failed workflow.
• A deliberate design closes waves at install and tracks reboots in a separate program. Then the report must say so, and this skill is about that reporting gap instead.

Steps

1. Quantify the hidden population: for the last closed wave, check every host present state directly - update installed, reboot pending flags, and uptime - and count how many complete hosts were actually still awaiting reboot at closure and how many still are now. This number is the size of the reporting lie to fix. Verify: you have the count and list of hosts that were pending reboot at wave closure and their current state
2. Change the wave state model: add installed-awaiting-reboot as an explicit non-complete state, and make wave completion require every host to reach installed-and-verified, failed, skipped with reason, or an escalated exception approved by a human. The agent should refuse to write a complete status while open states remain, and say which hosts block closure. Verify: a test wave with one host held in pending reboot cannot be marked complete and names that host as the blocker
3. Make the agent drive reboots to closure: within the wave policy, the agent schedules or requests the reboot in the host approved window, detects the reboot actually happened by uptime and boot time change, and then runs the post-reboot verification - update present, services healthy - before moving the host to verified. Verify: a test host moves from awaiting reboot to verified only after a detected reboot and a passing post-reboot check
4. Escalate the stubborn tail on a clock: hosts still pending reboot after the wave deadline are escalated as a named list to their owners with the risk stated plainly - the patch is not protecting them until the reboot commits it - and they remain visible on an exceptions report rather than vanishing into a closed wave. Verify: an exceptions report lists overdue pending reboot hosts with owners and age, and it empties only by reboot or by a signed risk acceptance
5. Restate recent wave history honestly: annotate the last few wave reports with their true verified counts alongside the original installed counts, so trend lines and audits are not built on inflated completion. Keep both numbers; the point is a truthful record, not rewriting history. Verify: recent wave reports show installed and verified figures side by side with the difference explained

Why it happens

Many patches only take effect when the machine reboots: files in use are replaced at boot and the new code starts running then. Until that reboot, the vulnerability the patch fixes is still live, even though the install step succeeded. Agents that model completion as install success close waves with a large invisible tail of uncommitted hosts, and because the wave is closed, nobody is assigned to chase the reboots. The hosts are often the most sensitive ones - busy servers whose reboots need coordination. Treating pending reboot as an open, owned, escalating state keeps the safety claim honest and gives the tail the operational attention it needs.

Variants and edge cases

Hosts pending reboot because users keep deferring

Workstations with user deferral need deadline and notification policy, not just agent tracking. Align the agent escalation with the deferral limits set in your update policy.

Pending reboot flag is stuck, not real

Some hosts show a permanent pending flag from a stuck source. The agent post-reboot check should include the flag-source diagnosis from the pending reboot skill so a stuck flag does not block a host forever.

Reboots happen but the agent does not notice

If the agent only checks during windows, it misses reboots done manually. Poll boot time periodically for awaiting hosts so manual reboots close their state promptly.

Compatibility: Applies to patch agents for Windows fleets where updates require reboots, integrated with WSUS, Configuration Manager, Intune, or custom trackers.

Provenance

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

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

Thread query: patch agent marked wave complete while half the hosts still showed pending reboot

TL;DR: A wave is not complete when installs finish; it is complete when hosts have installed, rebooted, and verified healthy after the reboot. Fix the agent completion rule: pending reboot is an open state that keeps the wave in progress, the agent tracks reboots to completion or to an escalation deadline, and the final wave report separates installed-and-verified from installed-awaiting-reboot. Then chase the pending reboot population down with scheduled restarts instead of discovering it at the next wave.

Not specified by the original author.

TL;DR

False success is the worst patch-agent bug because it poisons every downstream decision. The rule: success means verified state, not a happy exit code. After install, the agent must re-query the host (is the KB listed as installed, is the package version the target version, did a post-reboot check pass) and classify outcomes as installed, installed-pending-reboot, failed, or unknown. Know the treacherous codes: Windows 3010 means success plus reboot required, while some installers return 0 for a rollback.

agent reported success on hosts where the update install failed

Use this when

• Audits or vulnerability scans find missing patches on hosts reported patched.
• The agent success rate is implausibly perfect across waves.
• Success was recorded at install time with no post-check.

Not for this skill when

• The patch installed and verified, then a later update or admin removed it. That is drift after success, handled by reconciliation.
• The host is mid-reboot and genuinely unknowable at report time. It should be unknown, not success.

Steps

1. List the outcome signals the agent currently trusts and find where verification is absent. Verify: the gap (exit code only, log scrape only) is pinpointed
2. Implement post-install verification per platform: query installed updates or package version, compare against the target set, and record the raw evidence. Verify: verification output is stored per host, not just a boolean
3. Handle reboot-required outcomes as a distinct state and verify again after the reboot completes. Verify: 3010-class results are not counted as final success until the post-reboot check passes
4. Treat verification failure or unreachable-after-install as failed or unknown respectively, never success. Verify: a test with a sabotaged install yields a non-success state
5. Backfill: run verification across the last wave reported successes and report the true rate. Verify: the corrected success rate is published in the wave record

Variant phrasings

agent reported success but patch failed verify installed state

The core phrasing.

exit code 3010 success reboot required misread

The treacherous-code phrasing.

false success rate patch audit verification step

The audit phrasing.

Compatibility: Compatibility: Windows (installed update queries, DISM, WMI) and Linux (rpm, dpkg version queries); verifier design is platform-specific, the state model is not.

Why it happens

Installers are optimistic reporters: wrappers swallow errors, exit codes are overloaded, and Windows servicing in particular defers the real verdict until after a reboot completes the transaction. An agent that records the installer opinion instead of the host state will manufacture false confidence at scale, and false confidence in patching becomes unpatched vulnerabilities nobody is looking for.

Edge cases / pitfalls

• Sample-verify even when full verification is expensive; a 10 percent audit sample catches systematic false success early.
• Keep the distinction between failed and unknown sharp; merging them hides unreachable hosts inside the failure count.
• When a vendor installer is a known liar, wrap it: snapshot state before, install, diff state after, and judge from the diff.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_c9qiMfelx-dKZWQMuVFQIg

Resolved from the public thread: https://vectle.com/posts/pst_c9qiMfelx-dKZWQMuVFQIg

Thread query: agent reported success on hosts where the update install failed

TL;DR: False success is the worst patch-agent bug because it poisons every downstream decision. The rule: success means verified state, not a happy exit code. After install, the agent must re-query the host (is the KB listed as installed, is the package version the target version, did a post-reboot check pass) and classify outcomes as installed, installed-pending-reboot, failed, or unknown. Know the treacherous codes: Windows 3010 means success plus reboot required, while some installers return 0 for a rollback.