agent's checksum cache was poisoned by a partial download and verificat

Not specified by the original author.

TL;DR

A checksum cache is only trustworthy if entries are written after complete, verified downloads. A partial download that still writes its computed-so-far hash poisons every later check that trusts it. Write cache entries atomically only after size and hash verification passes, include the expected hash in the cache key, and evict and recompute any entry tied to an interrupted transfer.

agent's checksum cache was poisoned by a partial download and verification failed

Use this when

• Verification fails repeatedly for a file that verifies fine when downloaded fresh elsewhere.
• The first failure followed an interrupted or timed-out download.
• Clearing the agent cache makes the failure vanish once, then it can return after another interruption.

Not for this skill when

• The file in the repository is genuinely corrupt. Fresh downloads fail too, which exonerates the cache.
• The agent reads production cache instead of the restore. Provenance problem.

Steps

1. Reproduce by comparing the cached hash for the suspect file with a freshly computed hash of a complete download. Verify: cache and reality disagree, proving poisoning
2. Audit the cache write path for when entries are created relative to download completion. Verify: the premature write point is found
3. Change caching to write only after full size and hash checks pass, using a temporary entry promoted atomically. Verify: killing a download mid-way leaves no cache entry in tests
4. Key entries by object identifier plus expected hash or version so stale entries cannot masquerade as current. Verify: a changed object misses the old cache entry
5. Evict all entries created before the fix for affected repositories and run verification. Verify: checks pass on verified downloads

Variant phrasings

checksum cache poisoned partial download verification

The poisoning phrasing.

stale hash cache agent false corruption

The false-alarm variant.

cache only verified downloads atomic entry

The design wording.

Compatibility: Agents verifying restic, Borg, S3 and file-based backups with local checksum or metadata caches in Python and TypeScript.

Why it happens

Caches trade correctness risk for speed, and the risk concentrates exactly at failure boundaries: the interrupted download is both when wrong data appears and when bookkeeping is sloppiest. If the cache records the hash of whatever bytes arrived, later checks compare the repository against the accident, not against the truth, and report phantom corruption with total confidence.

Edge cases / pitfalls

• A cache that cannot be trusted is worse than no cache. Measure hit benefit before keeping the feature.
• Store the verification evidence with the cache entry so its provenance can be audited.
• After any poisoning incident, assume sibling entries from the same window are suspect. Evict by time range.

Provenance

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

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

Thread query: agent's checksum cache was poisoned by a partial download and verification failed

TL;DR: A checksum cache is only trustworthy if entries are written after complete, verified downloads. A partial download that still writes its computed-so-far hash poisons every later check that trusts it. Write cache entries atomically only after size and hash verification passes, include the expected hash in the cache key, and evict and recompute any entry tied to an interrupted transfer.

Not specified by the original author.

agent loop detected re-downloading same sam.gov attachment after checksum mismatch: how to fix it

A checksum mismatch on retry usually means the server file changed or the check is wrong, not that the download is corrupt. Verify the file independently, log the mismatch, and continue instead of looping.

agent loop detected re-downloading same sam.gov attachment after checksum mismatch

When to use this skill

• Agent downloads the same attachment repeatedly
• Checksum mismatch on every retry

When not to use this skill

• Download fails outright (a connection issue)
• File is actually corrupt (an integrity issue)

Tool compatibility

Agent download verification loops. Related area: agent frameworks.

Related area: proposal automation and agent-assisted RFP workflows.

Cloud UIs change labels over time; if a button moved, search settings for the closest match.

Before you start

• Sign in to the tool and keep one tab open so sessions stay clean
• Copy the exact error text and note the time it happened
• Set aside 15 to 20 minutes; most of these resolve in a single pass

Quick diagnosis

Make sure this is the right skill before you invest the 15 minutes.

• If you are dealing with agent downloads the same attachment repeatedly, start at step 1 below.
• If instead download fails outright (a connection issue), stop here; you need a different skill.
• If neither quite matches, compare your screen against the verbatim error block at the top; that block is exactly what this skill covers.

Fix it in steps

1. Verify the file independently

Open the downloaded file and confirm it is complete and readable.

Expected: Expected: file opens; content looks complete.

2. Compare against the listing

Check the file size against the size shown on the SAM.gov listing.

Expected: Expected: sizes match, suggesting the checksum is stale.

3. Log the mismatch and continue

Record the expected versus actual checksum, then move to the next file.

Expected: Expected: run proceeds instead of looping.

4. Flag for human review

Mark the file for a human to confirm at the end.

Expected: Expected: human verifies the one flagged file.

Confirm each step worked

Run through this checklist before moving on. If a check fails, redo that step instead of pushing ahead.

• Step 1 (verify the file independently): Expected: expected: file opens; content looks complete.
• Step 2 (compare against the listing): Expected: expected: sizes match, suggesting the checksum is stale.
• Step 3 (log the mismatch and continue): Expected: expected: run proceeds instead of looping.
• Step 4 (flag for human review): Expected: expected: human verifies the one flagged file.

Quick recap

1. Verify the file independently
2. Compare against the listing
3. Log the mismatch and continue
4. Flag for human review

Still stuck?

Gather three things: the exact error text, the time it happened, and what changed just before it broke. Check the vendor status page for an active incident. Then open a support ticket with those three things; it cuts the back-and-forth in half. For agent runs, attach the last 50 lines of the agent log too, since the loop or timeout signature in the log usually names the cause.

Variant phrasings

agent re-download checksum loop

Verify and move on. If this matches what you saw, the steps above apply as written.

sam.gov attachment checksum mismatch loop

Stale checksum is the likely cause. If this matches what you saw, the steps above apply as written.

Why it happens

Listings sometimes carry checksums from a previous file version, so the download is fine and the check is stale. Looping the download re-fetches the same correct bytes forever.

Edge cases

• Cap download retries per file at three; a fourth retry never helps
• Partial downloads also mismatch; check the file size before blaming the checksum
• Keep the mismatch log; it is evidence if the file later proves wrong

Provenance

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

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

Thread query: agent loop detected re-downloading same sam.gov attachment after checksum mismatch

TL;DR:

Not specified by the original author.

TL;DR

Clear the partial download and rebuild the apt cache: remove the broken package files from the apt archives partial folder, run apt clean and apt update, then let unattended-upgrades run in the foreground once so the broken pipe source (usually a full disk or a killed download) is visible. Prove it on one failing host before rolling it to the rest of hosts managed by that package manager, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

ubuntu unattended-upgrades failed with broken pipe error reading the apt cache after a partial download

Use this when

• You see this exact error or symptom: ubuntu unattended-upgrades failed with broken pipe error reading the apt cache after a partial download.
• The failure is in the Linux, macOS or FreeBSD package manager on the target hosts, and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one failing host first and capture the evidence before changing anything: check the package manager's own log and terminal output on one failing host (apt history and term logs, dnf history, zypper log, or brew doctor output), and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Clear the partial download and rebuild the apt cache: remove the broken package files from the apt archives partial folder, run apt clean and apt update, then let unattended-upgrades run in the foreground once so the broken pipe source (usually a full disk or a killed download) is visible. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Record the before and after state for this fix (the exact setting, record, or file changed) so the change can be reverted cleanly if the symptom returns in a different form. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: rerun the same package command on one host and confirm it completes and the package reports the expected version. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of hosts managed by that package manager in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

ubuntu unattended-upgrades failed with broken pipe error fix

The verbatim error or code phrasing for this fault in the Linux; the fix is the same one in the steps above.

ubuntu unattended-upgrades failed with broken pipe error reading the

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix ubuntu unattended-upgrades failed with broken pipe error

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Ubuntu and Debian (apt, dpkg, unattended-upgrades), RHEL 9 (dnf), SLES 15 (zypper), Arch (pacman), FreeBSD (pkg), macOS Homebrew, and Canonical Livepatch as named in the title.

Why it happens

This fault happens because the fault sits at a boundary between two systems, each of which reports its own side as healthy, so the evidence has to be lined up on both sides to see it. In this case the condition is the one named in the title, in the Linux, macOS or FreeBSD package manager on the target hosts: the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

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

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

Thread query: ubuntu unattended-upgrades failed with broken pipe error reading the apt cache after a partial download

TL;DR: Clear the partial download and rebuild the apt cache: remove the broken package files from the apt archives partial folder, run apt clean and apt update, then let unattended-upgrades run in the foreground once so the broken pipe source (usually a full disk or a killed download) is visible. Prove it on one failing host before rolling it to the rest of hosts managed by that package manager, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.