Skip to content

PROD-2311: record post-publish versionIDs via Fetch-layer poll (fixes mapping drift)#184

Draft
5PK wants to merge 2 commits into
mainfrom
PROD-2311-versionid-poll
Draft

PROD-2311: record post-publish versionIDs via Fetch-layer poll (fixes mapping drift)#184
5PK wants to merge 2 commits into
mainfrom
PROD-2311-versionid-poll

Conversation

@5PK

@5PK 5PK commented Jul 14, 2026

Copy link
Copy Markdown
Collaborator

Problem

Post-publish mapping bookkeeping recorded new targetVersionIDs by reading the start-of-run filesystem snapshot, which doesn't contain items created during the same run. Those lookups failed (Target content item N not found in filesystem), left the mapping's targetVersionID stale — causing change-detection drift on the next sync (false re-push / false conflicts) — and were mislabeled under "Auto-Publish Errors". Content itself was published fine; this is post-publish bookkeeping.

Fix — poll-until-diverges on the Fetch layer

Resolve each published item's fresh versionID by polling the Fetch layer (@agility/content-fetch, preview mode) until the observed versionID diverges from its pre-publish baseline:

  • updated item — baseline = mapping.targetVersionID → wait until observed != baseline
  • created item — baseline = 0 (absent) → wait until it appears

Why source-consistent (no drift): content-fetch shares the datasource with content-sync (the pull), so the versionID recorded here equals what the pull writes and what change-detection later compares against. For published items the preview and fetch layers agree, so polling preview is safe (only staged/unpublished items differ, and those never reach this path).

Status hint (backoff only): the Fetch-API sync-in-progress check (Management SDK) is used only to wait smartly while a CDN sync is running — never as an exit condition. Exit is divergence, bounded by a hard timeout + iteration cap:

  • created item that never appears → non-blocking mapping warning
  • update whose version never diverges (no-op republish) → keep baseline silently (already correct)

Backoff sleep in the not-diverged-and-not-in-progress window avoids hot-looping during the post-publish registration race.

Re-label

Mapping/refresh notices now print under a non-blocking "Mapping Update Warnings" header, separate from genuine (blocking) "Auto-Publish Errors" — closing the loop on the categorization PROD-2310 deferred. (Display-only here; on main these already don't affect the exit code.)

Changes

  • src/lib/mappers/resolve-published-version-ids.ts (new) — poll-until-diverges loop (injectable deps for testing) + content-fetch client builder + content/page version fetchers. Constants: POLL_TIMEOUT_MS=60s, POLL_BACKOFF_MS=2s, POLL_MAX_ITERATIONS=1000.
  • src/lib/mappers/mapping-version-updater.ts — source versionIDs from the poll instead of the fs snapshot; reworded the residual error.
  • src/core/push.ts — split the error summary (non-blocking mapping warnings).
  • src/lib/mappers/tests/resolve-published-version-ids.test.ts — diverge→record, missing-create→warn, no-op-update→keep-baseline, backoff, wait-on-in-progress.

npm run type-check passes. Jest not run (per request); tests added.

🤖 Generated with Claude Code

5PK and others added 2 commits July 14, 2026 13:15
…instead of stale snapshot

The post-publish mapping bookkeeping recorded new targetVersionIDs by reading the
start-of-run filesystem snapshot, which does not contain items CREATED during the
same run. Those lookups failed ("Target content item N not found in filesystem"),
left the mapping's targetVersionID stale (→ change-detection drift next sync), and
were mislabeled under "Auto-Publish Errors".

Fix: resolve each published item's fresh versionID by polling the Fetch layer via
@agility/content-fetch (preview mode) until the observed versionID DIVERGES from its
pre-publish baseline:
  - updated item: baseline = mapping.targetVersionID → wait until observed != baseline
  - created item: baseline = 0 (absent)             → wait until it appears

Staying on the Fetch layer keeps a single source of truth: content-fetch shares the
datasource with content-sync (the pull), so the recorded versionID matches what
change-detection later compares against — no source mismatch, no drift. (For published
items the preview and fetch layers agree, so preview is safe.)

The Fetch-API sync status (Management SDK) is used ONLY as a backoff hint — never as
an exit condition. The exit condition is divergence, bounded by a hard timeout:
  - created item that never appears  → non-blocking mapping warning
  - update whose version never diverges (no-op republish) → keep baseline silently

Also re-labels the summary: mapping/refresh notices now print under a non-blocking
"Mapping Update Warnings" header, separate from genuine (blocking) "Auto-Publish
Errors" — closing the loop on the categorization PROD-2310 deferred.

- src/lib/mappers/resolve-published-version-ids.ts (new): poll-until-diverges loop +
  content-fetch client builder + content/page version fetchers.
- src/lib/mappers/mapping-version-updater.ts: source versionIDs from the poll.
- src/core/push.ts: split the error summary (non-blocking mapping warnings).
- tests for the poll loop.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Newly-created items already carry a non-zero create-time targetVersionID in the
mapping (ContentItemMapper.addMapping), so baseline===0 was not a reliable "is
new" signal — a created item that never propagated to the Fetch API could be
silently kept instead of warned.

Track which ids were observed on the Fetch layer at least once and classify
leftovers by that: never observed -> non-blocking "missing" warning; observed
but never diverged (e.g. no-op republish) -> keep the existing mapping value
silently. Reworded the residual warning to "mapping version not updated" so it
is accurate for both zero and non-zero baselines. Added a test covering a
never-observed item with a non-zero baseline.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant