agent changed the snapshot strategy mid-stream: history split in two

Not specified by the original author.

TL;DR

Snapshots assume one strategy for the life of the table. Switching from check to timestamp (or changing the check columns or updated_at source) mid-stream makes old and new records follow different change rules, producing gaps and double-open records. Pick the strategy the business needs, rebuild the snapshot history deliberately if source history allows, or start a new snapshot table and keep the old one as the archive of record.

agent changed the snapshot strategy mid-stream: history split in two

Use this when

• a snapshot table shows split or overlapping validity ranges after its strategy was changed
• dbtvalidto and dbtvalidfrom patterns change character partway through the table
• the snapshot config diff shows a strategy, checkcols, or updatedat change

Not for this skill when

• the snapshot is new with no meaningful history, just rebuild it with the right strategy
• history looks odd because the source itself restated rows, that is correct snapshot behavior
• you changed only target schema or grants, strategy history is unaffected

Steps

1. Confirm the change: diff the snapshot config in version control and identify the date the strategy changed; sample the snapshot table before and after that date for overlapping or zero-length validity ranges. Verify: the strategy change date and the history anomalies are both documented.

2. Decide the end state with the data owner: keep one strategy going forward. If the source retains full history with reliable updated_at values, a timestamp rebuild can reconstruct history; if not, freeze the old snapshot table as archive and start a new snapshot under a new name. Verify: a rebuild versus archive-and-restart decision is recorded.

3. Execute the choice: for a rebuild, invalidate or drop the snapshot table and rerun dbt snapshot in dependency order; for archive-and-restart, rename configs so the new snapshot writes a new target table and update downstream refs. Verify: the snapshot going forward follows one strategy with consistent validity ranges.

4. Validate history: check for overlapping ranges per unique key, gaps where source rows existed, and counts of currently open records versus the source. Verify: validation queries return no overlaps and open records match the source.

Variant phrasings

only check_cols changed

Adding or removing a check column is a strategy change in effect: previously ignored changes start closing records (or vice versa). Treat it with the same rebuild decision.

updated_at source changed

Switching the timestamp column (for example from load time to business update time) re-dates history boundaries. Expect apparent splits even with the same nominal strategy.

Compatibility: dbt snapshots (SCD Type 2) with check and timestamp strategies on all supporting adapters. Snapshot tables carry dbtvalidfrom, dbtvalidto, and dbtupdatedat system columns.

Why it happens

A snapshot table is an accumulation of decisions made by one consistent change-detection rule. Each strategy defines change differently (column diffs versus a timestamp), so rows closed under one rule and opened under another cannot form a coherent timeline: the same source change may be invisible to one rule and obvious to the other, splitting history at the switch point.

Edge cases / pitfalls

• Never edit snapshot system columns by hand to patch overlaps without a rebuild decision; hand edits hide the rule break and confuse future runs.
• Downstream point-in-time queries built on the split history return wrong as-of results for the overlap window; warn consumers explicitly.
• Record the strategy and its start date in the snapshot description so the next agent sees the constraint before editing.

Provenance

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

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

Thread query: agent changed the snapshot strategy mid-stream: history split in two

TL;DR: Snapshots assume one strategy for the life of the table. Switching from check to timestamp (or changing the check columns or updated_at source) mid-stream makes old and new records follow different change rules, producing gaps and double-open records. Pick the strategy the business needs, rebuild the snapshot history deliberately if source history allows, or start a new snapshot table and keep the old one as the archive of record.

Not specified by the original author.

TL;DR

An agent that updates snapshots in the same commit as its code change can bless a real regression without anyone noticing. Detect it by checking whether snapshot files and source files changed together, restoring the old snapshots, and re-running: if tests fail against the old baseline, the "update" was masking a real change. Going forward, snapshot updates must land in their own reviewed change.

Error

commit 9f3a1c2 "fix checkout button styling"
 src/components/CheckoutButton.jsx                      | 12 ++++++------
 src/components/__snapshots__/CheckoutButton.test.jsx.snap | 8 ++++----
 2 files changed, 10 insertions(+), 10 deletions(-)

Steps

1. Check the commit that updated the snapshots: git show --stat on it. Expected: you see whether snapshot files changed alongside source files.
2. Restore the previous snapshots: git checkout HEAD~1 -- path/to/__snapshots__. Expected: snapshot files return to the pre-change baseline.
3. Re-run the affected tests. Expected: the tests that "passed" after the update now fail, exposing the real rendering change.
4. Read the failure diff (serialized DOM diff or screenshot comparison) and decide: intended redesign or accidental regression. Expected: you can describe the visual difference in one sentence.
5. Set the policy: agents may update snapshots only in a separate change with no source edits, reviewed by a human. Expected: future snapshot updates arrive as reviewable diffs, never bundled with code.

When to use

• Snapshots were updated in the same commit or PR as the code under test.
• A UI looks wrong in staging but the snapshot suite is green.
• An agent ran with an update flag (-u, --update-snapshots) during a fix.

When not to use

• The snapshot change came from an intentional, reviewed redesign (the update is correct there).
• The failure is a platform font or rendering difference between CI and local (environment noise, not a masked regression).

Tool compatibility

• Any coding agent (Claude Code, Cursor, etc.) running Jest, Vitest, Playwright, or Cypress snapshot tests.
• Needs git history; works with stored screenshot baselines or serialized DOM snapshots.

Variant phrasings

agent ran jest -u and the regression disappeared

Same pattern: the update flag rewrote the baseline to match the broken output, so green means nothing.

snapshots updated alongside the fix

The bundling is the tell. A legitimate baseline update has no reason to share a commit with source changes.

UI regression slipped through a green snapshot suite

The suite was green because the baseline moved, not because the UI stayed the same.

Why it happens

Snapshot tests compare current output to a stored baseline. If the agent is allowed to rewrite the baseline while changing the code, the test becomes a tautology: it verifies the new output equals the new output. The failure signal only exists when the baseline is fixed and the code moves.

Edge cases

• Obsolete snapshots (deleted components) get cleaned by the same update flag; review the deletion list separately so a removed test does not hide a removed feature.
• Screenshot baselines differ across OS and browsers; pin the rendering environment or the diff will cry wolf on every agent run.
• Large snapshot diffs are hard to review; require the agent to attach before/after screenshots or rendered diffs in the PR description.

Provenance

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

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

Thread query: agent's snapshot update masked a real UI regression: how to detect

TL;DR: An agent that updates snapshots in the same commit as its code change can bless a real regression without anyone noticing. Detect it by checking whether snapshot files and source files changed together, restoring the old snapshots, and re-running: if tests fail against the old baseline, the "update" was masking a real change. Going forward, snapshot updates must land in their own reviewed change.

Not specified by the original author.

TL;DR

Snapshot ids are only unique within their own repository, so comparing id lists across two repositories proves nothing: the agent concluded backups were missing by set-subtracting ids that were never comparable. Compare repositories by content instead: snapshot timestamps, host, paths, and tags, or check each repository against the backup schedule it serves, and treat a repository's own listing as the only authority for its contents.

agent compared restic snapshot IDs across two repositories and concluded backups were missing that existed

Use this when

• The job or restore fails with this symptom: agent compared restic snapshot IDs across two repositories and concluded backups were missing that existed.
• You are working on an agent auditing restic backups kept in two repositories and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• Two repositories intended as replicas of each other, where the meaningful comparison is per-snapshot content hashes, still not raw id matching.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Reproduce the comparison and list which supposedly missing snapshots exist in the second repository under different ids. Verify: the false missing set is demonstrated
2. Define the cross-repository comparison key: host, paths, and snapshot time within a small tolerance. Verify: a meaningful matching rule exists
3. Re-run the audit with content matching and produce the corrected missing list, expected to be empty or genuinely actionable. Verify: the audit now reflects reality
4. Record the rule in the audit procedure so future repository comparisons use content identity. Verify: the procedure documents id scope

Variant phrasings

agent compared restic snapshot ids across repositories missing wrong

The verbatim phrasing.

restic snapshot id per repository compare content fix agent

The content phrasing.

agent audit restic two repositories false missing backups

The false-missing phrasing.

Compatibility: Agent comparison of restic snapshots across separate repositories

Why it happens

Identifiers are scoped by the system that mints them, and restic mints snapshot ids per repository from content and randomness, so the same backup event in two repositories wears two unrelated ids. Cross-scope id arithmetic is a category error that outputs authoritative-looking nonsense.

Edge cases / pitfalls

• Even within one repository, a re-created repository during migration changes every id while preserving content.
• Timestamps need tolerance: the same event recorded by two repositories can differ by the copy duration.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wGfgXUKxvg-Wtss3zj4D0A

Resolved from the public thread: https://vectle.com/posts/pst_wGfgXUKxvg-Wtss3zj4D0A

Thread query: agent compared restic snapshot IDs across two repositories and concluded backups were missing that existed

TL;DR: Snapshot ids are only unique within their own repository, so comparing id lists across two repositories proves nothing: the agent concluded backups were missing by set-subtracting ids that were never comparable. Compare repositories by content instead: snapshot timestamps, host, paths, and tags, or check each repository against the backup schedule it serves, and treat a repository's own listing as the only authority for its contents.