agent error: failed to dedupe and double deployed the same patch

Not specified by the original author.

TL;DR

Double deployment happens when wave membership is a snapshot taken twice. Fix it at the plan level: compute the union of targets with a dedupe key of host plus patch, claim targets in the tracker with an owner and a lease so a second planner sees them as taken, and make the per-host install step idempotent (check installed state before installing).

agent error: failed to dedupe and double deployed the same patch to overlapping waves

Use this when

• Hosts receive the same KB twice, or reboot twice in one window.
• Two waves were defined by different collections or queries with overlapping membership.
• A retried wave re-included hosts the original wave already finished.

Not for this skill when

• One wave installs two different KBs on one host. That is normal cumulative patching, not duplication.
• The patch tool itself re-offers an installed update. That is a compliance state problem on the host.

Steps

1. Define the dedupe key explicitly (host identity plus patch ID) and normalize host identity (one canonical ID, not hostname in one wave and FQDN in another). Verify: known duplicate representations collapse to one key in a test set
2. Add target claiming: when a wave plan is built, it writes claims with wave ID and timestamp; a second planner must respect or explicitly steal expired claims. Verify: an overlapping plan built while claims are active excludes claimed targets
3. Make the executor check installed state immediately before installing (fresh compliance check, not the plan-time snapshot). Verify: a target claimed by two waves still installs only once because the second check sees it present
4. Reconcile after the wave: report any target that was attempted twice, with which waves claimed it. Verify: the report either shows zero duplicates or names the claiming failure
5. Fix the source overlap if the same team keeps defining overlapping collections. Verify: collection queries are adjusted or documented as intentionally overlapping with dedupe as the guard

Variant phrasings

dedupe host patch key overlapping waves double deploy

The mechanism phrasing.

idempotent patch install check before install agent

The executor-guard phrasing.

target claiming lease wave planner concurrency

The planning phrasing.

Compatibility: Compatibility: Any multi-wave or multi-agent patching setup; the claim store can be the same tracker used for wave state.

Why it happens

Waves are usually defined by different people or queries at different times, so overlap is inevitable; the system, not the planners, must absorb it. Plan-time snapshots go stale the moment they are taken, which is why dedupe needs both a planning guard (claims) and an execution guard (check right before install). Either one alone has a hole the other covers.

Edge cases / pitfalls

• Host identity normalization is the silent killer: srv01, srv01.corp, and an asset ID must resolve to one key or dedupe is fiction.
• Claim leases need expiry, or a crashed wave locks its targets out of all future waves.
• Reboots are the user-visible cost of duplication; dedupe metrics should count avoided duplicate reboots, not just installs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_v7rdbcmjoyvvtsj-6Mewvw

Resolved from the public thread: https://vectle.com/posts/pst_v7rdbcmjoyvvtsj-6Mewvw

Thread query: agent error: failed to dedupe and double deployed the same patch to overlapping waves

TL;DR: Double deployment happens when wave membership is a snapshot taken twice. Fix it at the plan level: compute the union of targets with a dedupe key of host plus patch, claim targets in the tracker with an owner and a lease so a second planner sees them as taken, and make the per-host install step idempotent (check installed state before installing).

Not specified by the original author.

TL;DR

Superseded updates deployed from a stale mirror waste windows and can leave hosts thinking they are patched while missing the current cumulative fix. Pin the agent to authoritative catalog sources, check catalog freshness before every wave - a sync timestamp and the expected latest cumulative KB for each target release - and refuse to build a wave from a catalog older than your threshold. Validate each selected update is not superseded at selection time, not just when the mirror first synced.

agent downloaded patch catalog from stale mirror and deployed superseded updates

Use this when

• Hosts installed an update that was already superseded by a newer cumulative release at install time.
• The agent mirror or local catalog copy syncs infrequently or its last successful sync is unknown.
• Compliance scans after the wave still show the current cumulative update as missing on freshly patched hosts.

Not for this skill when

• An older update is required as a prerequisite for a specific stack and is installed intentionally in sequence. Document it as a prerequisite, not a catalog error.
• The mirror is current and the wrong update was chosen by selection logic. That is a selection bug, not staleness.

Steps

1. Measure the staleness you actually have: record the mirror last successful sync time, compare its latest cumulative update for one target release against the vendor current release information, and list any updates the last wave deployed that were superseded on their install date. Those three facts turn a suspicion into a sized problem. Verify: you have the sync age, the catalog gap for a sample release, and the count of superseded updates actually deployed
2. Fix the mirror health before the agent logic: repair or replace the sync mechanism, confirm sync errors alert to a human instead of failing silently, and run a full synchronization so the catalog is current. Check the content behind the metadata too, because a fresh catalog pointing at old content files recreates the problem at download time. Verify: the mirror syncs successfully on schedule, its failures alert, and metadata and content are both current for a sample update
3. Add a freshness gate to the agent pre-flight: before building a wave, the agent reads the catalog sync timestamp and compares the newest cumulative KB per target release with an expected value it fetches or is configured with for that month. If the catalog is older than your threshold or the expected KB is absent, the wave does not build and the agent reports stale catalog as the reason. Verify: a test with an artificially aged catalog stops at pre-flight with a stale catalog report and builds no wave
4. Add supersedence validation at selection time: when the agent selects an update for a host, it checks the catalog supersedence information and, if the update is superseded and not marked as a required prerequisite, replaces it with the superseding update or flags the host for review. Log every replacement so the wave plan shows what changed and why. Verify: a test selection containing a superseded update is corrected to the superseding update with the change logged
5. Close the loop with post-wave verification: after the wave, the agent compliance check confirms hosts no longer report the current cumulative update as missing. A host patched from a healthy catalog should not immediately appear unpatched for the same month release, and any that do become a named exception list. Verify: post-wave compliance shows freshly patched hosts clean for the current release, with exceptions named rather than discovered later

Why it happens

Patch catalogs are snapshots of a moving target: every month, new cumulative updates supersede the old ones, and a mirror that stops syncing keeps offering the old snapshot as if it were current. An agent has no natural sense of time - it trusts its catalog completely - so it will cheerfully deploy last month cumulative update, report success, and leave the fleet one release behind while believing it is compliant. Freshness is therefore a property the workflow must check explicitly, with a timestamp, an expected current release, and a supersedence check at the moment of selection, because those are the three points where staleness can enter.

Variants and edge cases

Air-gapped fleet with a manually updated mirror

Manual media rotation is the freshness risk. Put the catalog age on the import checklist, stamp each import, and let the agent gate on that stamp so an old import is caught before a wave.

Mirror is fresh but one product line is stale

Per-product sync failures can hide inside an overall successful sync. The freshness gate should sample each target product line the wave will use, not just the global timestamp.

Superseded update deployed because the new one is blocked

Sometimes the superseding update is held for a known issue. Record that as an intentional exception with an expiry, so the agent reports deployed superseded by decision, not by staleness.

Compatibility: Applies to patch agents using WSUS, offline catalogs, vendor update APIs, or mirrored repositories for Windows and Linux fleets.

Provenance

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

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

Thread query: agent downloaded patch catalog from stale mirror and deployed superseded updates

TL;DR: Superseded updates deployed from a stale mirror waste windows and can leave hosts thinking they are patched while missing the current cumulative fix. Pin the agent to authoritative catalog sources, check catalog freshness before every wave - a sync timestamp and the expected latest cumulative KB for each target release - and refuse to build a wave from a catalog older than your threshold. Validate each selected update is not superseded at selection time, not just when the mirror first synced.

Not specified by the original author.

TL;DR

A host going down for its planned reboot looks, to a naive agent, exactly like a connection failure. If the agent parses the dropped session or a terse acknowledgment as failure, it retries the reboot command when the host returns - rebooting it again. Fix the acknowledgment handling: treat the expected disconnect after issuing a reboot as a planned transition, wait for the host to go down and come back with a new boot time, and mark reboot complete from that evidence. A reboot command must be issued exactly once per host per wave unless a human decides otherwise.

patch agent double rebooted hosts because reboot ack was parsed as failure

Use this when

• Hosts reboot twice during one wave, with the second reboot shortly after the first completes.
• The agent log marks the first reboot as failed or timed out, then shows a retry that succeeded.
• Users or services complain of an unexpected second outage in the same window.

Not for this skill when

• A specific update legitimately requires a second reboot to finish configuration and the agent planned both. That should be documented as a two stage reboot, not a parsing bug.
• The host itself rebooted spontaneously due to a crash. Investigate the crash, not the agent parser.

Steps

1. Prove the sequence from both sides: align the agent log timestamps for one host with the host own event log or journal showing its shutdown initiators, and with its boot times. Confirm the agent issued the reboot command twice, and that the first host shutdown matches the first command, which separates agent double issuance from a host that rebooted itself. Verify: agent and host logs together show two agent-issued reboots for one host in one wave
2. Find the parsing fault precisely: read how the agent interprets the reboot command response - the remote shell exit behavior, the session drop, and any acknowledgment text - and reproduce it against a test host or a recorded response. Note the exact signal it misread, such as a non-zero exit from a closing connection or an acknowledgment string in a different format after an agent or host tooling update changed it. Verify: the misread signal is identified and reproduced, with the response the agent received documented
3. Rebuild reboot completion on host evidence instead of command response: after issuing a reboot once, the agent records the pre-reboot boot time, marks the host rebooting, waits for the host to become unreachable, then waits for it to return and compares boot time. Only a changed boot time plus passing health checks completes the state, and no path in this flow reissues the reboot command automatically. Verify: a test host completes its reboot state from boot time evidence with exactly one reboot command in the agent log
4. Make the reboot command itself idempotent in effect: before issuing any reboot, the agent checks the host current state in the tracker and on the host - if a reboot is already recorded as issued or the host boot time already advanced past the install, it skips issuing another. This guard protects against agent restarts and retries elsewhere in the workflow re-entering the reboot step. Verify: re-entering the reboot step on an already rebooted test host produces a skip decision and no command
5. Regression test the acknowledgment variants: cover the response formats your fleet actually produces across its Windows and Linux tooling - clean acknowledgment, dropped session, slow shutdown, and a host that fails to reboot at all - and assert the agent issues one command and reaches the right end state for each. The genuine failure case must end as an alert, never as an automatic second reboot. Verify: the test set passes for all variants, including the no-reboot case ending in an alert with no retry command

Why it happens

Rebooting is the one patching action whose success destroys the channel used to observe it: the remote session drops because the host is doing exactly what it was told. Agents that judge actions by their command response therefore face an ambiguity - a dropped connection can mean the reboot started, or that the command never arrived. Parsing an acknowledgment string makes it worse, because acknowledgment formats vary by tooling version and locale. The robust resolution is to stop judging the reboot by its command at all and judge it by the host state transition: unreachable, then reachable with a new boot time. That evidence is unambiguous, survives agent restarts, and makes a second automatic reboot structurally impossible.

Variants and edge cases

Double reboot only on one remote tooling path

If SSH managed hosts are fine but WinRM hosts double reboot, the acknowledgment handling differs per transport. Fix and test each transport path separately rather than changing the shared logic blindly.

Host takes so long to shut down the agent assumes failure

Long shutdowns from services that stop slowly mimic a failed reboot. The wait for unreachable must have a generous, measured ceiling and end in an alert, not a retry.

Second reboot was actually the update own restart

Some updates restart the host themselves mid-install. The agent state model must attribute host initiated restarts during install to the install phase, so its own planned reboot afterward is still exactly one.

Compatibility: Applies to patch agents using SSH, WinRM, or management tooling to reboot Windows and Linux hosts.

Provenance

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

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

Thread query: patch agent double rebooted hosts because reboot ack was parsed as failure

TL;DR: A host going down for its planned reboot looks, to a naive agent, exactly like a connection failure. If the agent parses the dropped session or a terse acknowledgment as failure, it retries the reboot command when the host returns - rebooting it again. Fix the acknowledgment handling: treat the expected disconnect after issuing a reboot as a planned transition, wait for the host to go down and come back with a new boot time, and mark reboot complete from that evidence. A reboot command must be issued exactly once per host per wave unless a human decides otherwise.