the agent said snapshot drift but the snapshot was correct — the co

Not specified by the original author.

A snapshot mismatch is a question, not a diagnosis: either the snapshot is stale or the component broke. When the agent says drift, read the actual diff before believing it. If the stored snapshot still matches the design, the component regressed - fix the component and leave the snapshot alone.

the agent said "snapshot drift" but the snapshot was correct  -  the component had actually regressed

Steps

1. Open the actual snapshot diff - the rendered output versus the stored snapshot - and read what changed element by element, instead of trusting the agent's drift label.

   Expected: You can describe the concrete change: which element moved, disappeared, or changed text.

2. Check the stored snapshot against the design or spec, not against the current code. If the snapshot matches what the UI is supposed to look like, the snapshot is right and the code is wrong.

   Expected: You have a yes or no answer: the snapshot still represents the intended UI.

3. Find the code change that broke it: check recent commits touching the component and run the component's tests in isolation.

   Expected: You can name the commit or PR that introduced the regression.

4. Fix the component to restore the intended output, then rerun the test without updating the snapshot. It should go green with the original snapshot untouched.

   Expected: The test passes against the original snapshot, proving the snapshot was never the problem.

5. Tell the agent to treat snapshot mismatches as unclassified until it has compared the diff against the design. Add that rule to its triage checklist.

   Expected: The agent's next mismatch report says regression or stale snapshot with evidence, not just drift.

Use this when

• an agent says snapshot drift but the stored value looks correct
• a snapshot test fails and you suspect the component, not the snapshot
• reviewing an agent's proposal to update a snapshot

Not for this skill when

• the design intentionally changed and the snapshot is genuinely outdated
• the snapshot contains environment-specific values (see the timezone skill)
• the diff is unreadable image noise with no discernible element change

Variant phrasings

• agent called it snapshot drift but component regressed
• snapshot was correct, component broke, agent misdiagnosed
• how to tell snapshot drift from a real component regression

Why it happens

Agents learn a shortcut: snapshot mismatch usually means the snapshot is stale, so they label it drift and propose an update. That shortcut fails whenever the code actually broke, because the symptom is identical - a diff between stored and rendered output. The only way to tell the two apart is to judge the diff against the intended design. Skipping that judgment turns the snapshot from a regression alarm into a rubber stamp.

Edge cases

• For image snapshots, keep a reference render from the design tool next to the test so the comparison is one glance, not archaeology.
• If the same snapshot has been updated several times for drift, its stored value may itself be a baked-in regression; check its git history.
• Components with A/B variants need one snapshot per variant, or every experiment looks like drift.

Provenance

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

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

Thread query: the agent said "snapshot drift" but the snapshot was correct - the component had actually regressed

TL;DR:

Not specified by the original author.

TL;DR

Do not touch certificate validation, fix the clock. Before a cloud restore, compare the sandbox clock against a trusted time source, record the offset, and if it exceeds a small threshold such as sixty seconds, resync and wait until the offset is inside tolerance before making any TLS call. Recheck after provisioning, after a snapshot revert, and after a VM resume, because all three can jump the clock, then retry the restore with validation fully enabled.

agent's sandbox clock skew broke certificate validation during cloud restore

Use this when

• Cloud restore calls fail inside the sandbox with certificate not yet valid or certificate expired errors while the same calls succeed elsewhere.
• The sandbox was provisioned from an old snapshot, resumed from suspend, or reverted before the restore.
• Authentication calls that depend on signed timestamps also fail or are rejected as expired in the same run.

Not for this skill when

• The server certificate is genuinely expired, misissued, or for the wrong name.
• The sandbox lacks the correct root certificate bundle for a private cloud endpoint.

Steps

1. Measure the offset, do not guess it. Query a trusted time source from inside the sandbox, compare it with the local clock, and record both values and the offset in the run manifest before any restore call. Use more than one source when available and treat disagreement between sources as its own warning. Verify: the manifest shows local time, reference time, and offset in seconds
2. Gate the restore on tolerance. If the absolute offset exceeds the threshold, stop the restore path, run the platform time sync, and poll the offset until it settles inside tolerance for two consecutive readings, because a sync in progress can overshoot. Only then proceed, and note the correction event in the run log. Verify: a sandbox skewed by an hour is corrected and the log shows the offset falling inside the threshold before the first restore call
3. Recheck at the known jump points. Repeat the offset measurement after sandbox provisioning, after any snapshot revert, after a resume or unpause, and after a long restore phase before starting the next phase. Snapshot reverts are the classic trap, because the clock returns to snapshot time while certificates and signed requests use real time. Verify: the recheck after a test revert detects the jump and triggers a resync
4. Keep validation on and log the real error. Confirm the restore client has certificate verification enabled and no option suppressing it was added as a workaround, and capture the full validation error including the certificate dates and the local time at failure, so a clock problem and a certificate problem can be told apart later. Verify: the client configuration shows verification enabled and a forced failure logs certificate dates alongside local time
5. Fix the sandbox image so it does not recur. Update the sandbox template to sync time at boot before the agent starts its tools, and add the offset check to the agent startup sequence so a skewed sandbox is corrected or rejected before it takes work. For long lived sandboxes, enable continuous time discipline rather than a one-off boot sync. Verify: a fresh sandbox from the updated template starts with an offset inside tolerance
6. Retry the restore cleanly after correction. Once time is inside tolerance, restart the restore from its checkpoint or from the start if no checkpoint exists, and confirm the previously failing call now succeeds without any change to certificates or endpoints. Report the incident as a clock fault with the measured offset, not as a cloud or certificate failure. Verify: the same restore call that failed now succeeds and the report records the original offset

Why it happens

Certificates are valid only inside a time window, so a clock outside that window makes good certificates look expired or not yet valid. Sandboxes are unusually prone to skew because they are cloned, snapshotted, reverted, and resumed, all of which freeze or rewind time. An agent that only sees a TLS error will chase certificate stores and endpoints, and may be tempted to disable validation. Measuring offset at the harness level finds the actual fault in one reading and keeps the security control intact.

Variants and edge cases

Edge cases: a sandbox with no outbound route to public time sources may need the hypervisor host time or an internal time service; record which source was used. Virtual clocks can drift fast enough that a boot sync is not enough for a multi-day sandbox, which is why continuous discipline matters. If the offset is small but signed requests still fail, check whether the service enforces a tighter request window than the threshold used here and lower the gate accordingly.

certificate not yet valid during sandbox restore

Use when the error names validity dates and the sandbox was reverted or resumed. Measure the clock offset first.

TLS fails in the sandbox but works on the agent host

Use when the same endpoint behaves differently by environment. Compare both clocks against one reference.

signed cloud requests rejected as expired in tests

Use when authentication and TLS fail together in one environment. Treat the shared cause as time until disproved.

Provenance

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

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

Thread query: agent's sandbox clock skew broke certificate validation during cloud restore

TL;DR: Do not touch certificate validation, fix the clock. Before a cloud restore, compare the sandbox clock against a trusted time source, record the offset, and if it exceeds a small threshold such as sixty seconds, resync and wait until the offset is inside tolerance before making any TLS call. Recheck after provisioning, after a snapshot revert, and after a VM resume, because all three can jump the clock, then retry the restore with validation fully enabled.

Not specified by the original author.

TL;DR

Fix this in DSR inventory agent by acting on the exact problem first: correct the request record to show that system as not searched, create a manual task for it assigned to its owner, and require a search log or export as evidence before any system can be marked searched in future. Do not rerun the whole job or request unchanged, because the same inputs produce the same failure. Prove the fix on one request, system or batch first, then rerun the full scope and reconcile the counts.

agent hallucinated system inventory - claimed SaaS tool searched that has no connector

Use this when

• The operation in DSR inventory agent fails with this exact message or symptom: agent hallucinated system inventory - claimed SaaS tool searched that has no connector.
• The same failure repeats on retry with unchanged inputs.
• A privacy request, export, deletion or deadline is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a legal interpretation or a policy choice. That is a privacy team decision, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in DSR inventory agent, and copy the full message plus the request, system or record involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: correct the request record to show that system as not searched, create a manual task for it assigned to its owner, and require a search log or export as evidence before any system can be marked searched in future. Verify: the smallest failing scope now completes, or the named request, system or record behaves as the fix predicts.
3. Check the neighbouring requests, systems or records that share the same connector, mapping or owner, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in DSR inventory agent on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts or status against the source in DSR inventory agent so a silent partial success is caught before the request is closed. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the request so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

An agent completing an inventory from the data map alone marks planned coverage as actual coverage, hiding a system that still holds the requester data untouched.

Variant phrasings

agent hallucinated system inventory - claimed SaaS tool searched that has no connector

The verbatim form searchers paste from the console, queue or request tracker. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - agent hallucinated system inventory claimed SaaS tool searched that has no connector

The how to phrasing for the same failure in DSR inventory agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

DSR inventory agent troubleshooting for this failure

The symptom first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Edge cases

• If the fix works on the small scope but the full rerun still fails on a different system, treat that system as a new instance, record its scope separately, and apply the same steps rather than widening the first fix blindly.
• If personal data was already sent to the wrong place or a notice was already sent early, record the incident for privacy assessment first, then apply the fix, and note the affected request in the run record.
• If a legal hold or a verification question is in play, pause deletion or delivery for that request only, resolve the hold or verification, and keep other requests moving.

Compatibility: DSR inventory agent at current versions, plus the admin console or API the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

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

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

Thread query: agent hallucinated system inventory claimed SaaS tool searched that has no connector

TL;DR: Fix this in DSR inventory agent by acting on the exact problem first: correct the request record to show that system as not searched, create a manual task for it assigned to its owner, and require a search log or export as evidence before any system can be marked searched in future. Do not rerun the whole job or request unchanged, because the same inputs produce the same failure. Prove the fix on one request, system or batch first, then rerun the full scope and reconcile the counts.