Edge Cache Consistency After Switching From Build-Time Deploys to On-Demand Revalidation

Edge cache consistency after switching from build-time deploys to on-demand revalidation

The goal is to determine whether a browser request for a static asset immediately after on-demand revalidation returns the pre-deploy or post-deploy representation. This assumes a Jamstack host that supports on-demand revalidation; Jamstack itself is an architecture, not a versioned product, so no universal consistency contract exists across providers.

Moving from build-time publishing to on-demand regeneration shifts the consistency boundary from build completion to revalidation completion. Edge propagation remains eventual and depends on the CDN, plan, TTL, stale-while-revalidate settings, and browser cache headers. Idempotency keys for retries belong to the backend API, not the static frontend.

Which provider and plan behaviors control immediate visibility after revalidation? Does an instant purge API apply to on-demand revalidation or only full builds? What client behavior is appropriate for responses received during the propagation window?