docs: tagged checkpoints do work on cloud-protected VPGs #11

2026-09-22T18:04:47-04:00

claude commented

2026-09-22 18:04:47 -04:00

The repo asserted, in four places, that a tagged checkpoint cannot be inserted when the protected site is Azure or AWS. That came from the 9.0 API reference. It is wrong on 10.9.10.

Measured against the lab: both an AWS-protected and an Azure-protected VPG accepted the insert, the Zerto task reached Completed, and the checkpoint appeared in the journal.

CMH-AWS-1      (AWS-protected)  : POST accepted, task -> Completed after 4s
Demo-VPG-Azure (Azure-protected): POST accepted, task -> Completed after 3s

Demo-VPG-Azure : TAG APPEARED after  34s  cp 1305
CMH-AWS-1      : TAG APPEARED after 128s  cp 121

Second doc claim this repo carried that live 10.9 contradicts, after the VPG status enum (filed as justin/zerto-docs#89).

What actually differs

Latency and granularity, both set by the protected site:

protected at	journal gap	tag visible after
vSphere	5s	~4s
Azure	60s	~34s
AWS	630s	~128s

The sharper consequence

The tagged checkpoint is stamped about 30s after the insert request. On a cloud-protected VPG an agent that mutates promptly puts its change inside the checkpoint that was supposed to precede it, so recovering from that tag restores the broken state. The docs now say to use the newest checkpoint that already existed when the guard ran.

Two of the four were message text

wait_for_tag's timeout message asserted the insert was unsupported, when the real cause was its own 45s budget being far too short for a VPG that checkpoints every 630s. It told operators the wrong thing at exactly the moment they were trying to diagnose a refusal. It now points at the Zerto task instead.

The 45s timeout itself is still wrong for cloud sources and needs to become cadence-aware. That is a behaviour change, so it is not in this PR.

Files: README.md, skills/zerto-rewind/SKILL.md, src/zerto_rewind_mcp/server.py, src/zerto_rewind_mcp/checkpoints.py. CONTEXT.md and docs/recover-ladder.md never carried the claim.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

The repo asserted, in four places, that a tagged checkpoint cannot be inserted when the protected site is Azure or AWS. That came from the 9.0 API reference. **It is wrong on 10.9.10.** Measured against the lab: both an AWS-protected and an Azure-protected VPG accepted the insert, the Zerto task reached `Completed`, and the checkpoint appeared in the journal. ``` CMH-AWS-1 (AWS-protected) : POST accepted, task -> Completed after 4s Demo-VPG-Azure (Azure-protected): POST accepted, task -> Completed after 3s Demo-VPG-Azure : TAG APPEARED after 34s cp 1305 CMH-AWS-1 : TAG APPEARED after 128s cp 121 ``` Second doc claim this repo carried that live 10.9 contradicts, after the VPG status enum (filed as `justin/zerto-docs#89`). ## What actually differs Latency and granularity, both set by the **protected** site: | protected at | journal gap | tag visible after | |---|---|---| | vSphere | 5s | ~4s | | Azure | 60s | ~34s | | AWS | 630s | ~128s | ## The sharper consequence The tagged checkpoint is stamped about **30s after** the insert request. On a cloud-protected VPG an agent that mutates promptly puts its change *inside* the checkpoint that was supposed to precede it, so recovering from that tag restores the broken state. The docs now say to use the newest checkpoint that already existed when the guard ran. ## Two of the four were message text `wait_for_tag`'s timeout message asserted the insert was unsupported, when the real cause was its own 45s budget being far too short for a VPG that checkpoints every 630s. It told operators the wrong thing at exactly the moment they were trying to diagnose a refusal. It now points at the Zerto task instead. **The 45s timeout itself is still wrong** for cloud sources and needs to become cadence-aware. That is a behaviour change, so it is not in this PR. Files: `README.md`, `skills/zerto-rewind/SKILL.md`, `src/zerto_rewind_mcp/server.py`, `src/zerto_rewind_mcp/checkpoints.py`. `CONTEXT.md` and `docs/recover-ladder.md` never carried the claim. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

claude added 1 commit 2026-09-22 18:04:48 -04:00

docs: tagged checkpoints do work on cloud-protected VPGs 5a75876f9f

The repo said, in four places, that a tagged checkpoint cannot be inserted
when the protected site is Azure or AWS. That came from the 9.0 API
reference. It is wrong on 10.9.10.

Measured against the lab: both an AWS-protected and an Azure-protected VPG
accepted the insert, the Zerto task reached Completed, and the checkpoint
appeared in the journal. This is the second doc claim this repo carried
that live 10.9 contradicts, after the VPG status enum.

What actually differs is latency and granularity, and both are set by the
PROTECTED site, not the recovery site:

  protected at   journal gap   tag visible after
  vSphere        5s            ~4s
  Azure          60s           ~34s
  AWS            630s          ~128s

There is a sharper consequence than slowness. The tagged checkpoint is
stamped about 30s AFTER the insert request, so on a cloud-protected VPG an
agent that mutates promptly puts its change inside the checkpoint that was
supposed to precede it. Recovering from that tag would restore the broken
state. The docs now say to use the newest checkpoint that already existed
when the guard ran.

Two of the four were message text, not prose. wait_for_tag's timeout
message asserted the insert was unsupported when the real cause was its own
45s budget being far too short for a VPG that checkpoints every 630s, so it
told operators the wrong thing at exactly the wrong moment. It now says to
check the Zerto task before concluding the insert failed.

The 45s timeout itself is still wrong for cloud sources and needs to become
cadence-aware. That is a behaviour change, so it is not in this commit.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

claude referenced this pull request

2026-09-22 18:05:55 -04:00

feat(hooks): enforce the guard from a PreToolUse hook #9

claude merged commit 3d487e0850 into main

2026-09-22 19:39:07 -04:00

claude deleted branch docs/cloud-tagging-correction

2026-09-22 19:39:07 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: justin/zerto-ai-rewind#11