Worker Previews — Pin the Whole Request Chain
## Overview
A live two-Worker reference built around paired branch-ui and branch-api Previews with explicit configuration and persisted telemetry. Advancing branch-ui from r1 to r2 changes its stable URL while the original fixed deployment stays callable. The same fixed r1 caller demonstrates both behaviors: its stable-target route reaches r2, while its captured fixed-target route keeps both executable versions pinned. A response inspector compares provider receipts and expected caller/target IDs with actual CF_VERSION_METADATA. The advanced lane retains ten uploaded Version URLs, moving upload aliases, and a fetch-style service-binding override to the production deployment's 0% candidate. Account-bound ownership checks run before mutations; pending receipts and deletion progress make the Preview lifecycle resumable without overwriting fixed history. The hosted showcase runs the public reference's neutral Workers.
## Highlights
- -> Paired named Previews have explicit vars, version metadata, logs, and traces; creating or advancing them leaves production unchanged
- -> The same fixed r1 caller reaches r2 through a stable target URL, or replays r1 through its captured fixed target URL
- -> Provider resource/deployment IDs and returned URLs are recorded separately from executing version IDs, with pending verification and resumable caller-first cleanup
- -> Ten fixed uploaded versions and moving aliases stay separate from the active-deployment service-binding override to a 0% candidate
- -> Recorded selectors, target-owned HTTPS origins, manual redirects, 10-second timeouts, bounded responses, and exact-origin CORS constrain every diagnostic call
## Architecture
Browser / target showcase
├── Production caller Worker
│ ├── captured stable Preview URLs ── branch-ui / branch-api latest
│ ├── captured fixed deployment URLs ── retained revision history
│ ├── fixed Version URLs / upload aliases ── ten uploaded versions
│ └── service binding + version override ── 0% candidate
│
└── Same fixed caller Preview deployment (r1)
├── stable target branch URL ── target r2 (moving)
└── fixed target deployment URL ── target r1 (both hops pinned)
Preview pairing uses public HTTP: Preview service bindings resolve to production.
Actual caller + target version IDs are compared with captured expectations.
Production remains 100% showcase / 0% candidate; pinning code does not freeze data.