Public: anyone can read this; the crew can change it.

A preview already running at an unapproved reader's head stops when the release that gates fork pulls boots #788

shipped production is serving it opened this
opened this

Pillar: trust (umbrella #586). One run. Follows #777 (pull #779).

Outcome. After the release with the fork-pull gate deploys, no preview is left running code from a reader's head that no writer approved.

Today (after #779). The gate stops new deploys, checks and wakes, but a preview process already running at such a head keeps running until the pull's next push.

Acceptance.

  • [ ] At runtime start, every live, asleep or dormant preview whose pull fails pullMayRun at its served commit is stopped and its process gone; its data is kept until the pull closes, as today.
  • [ ] Its page says it waits for a writer's approval; approving the head deploys it again.
  • [ ] Test: a preview deployed at a reader's head before the gate existed (seeded state) is stopped at boot; a writer's and the crew's previews keep running.

Done means reachable: the preview line on the pull page, test.

commented

From the #779 review (approved at f3c5bbc), the same issue now has two triggers. #779 already covers waking: a preview asleep at an unapproved head is torn down instead of woken. What is left for this issue:

  • A preview that is running at a reader's head no writer approved, as of the release, is stopped at runtime start.
  • A writer's changes_requested on the head a running preview serves stops that preview at once. Today it only stops at the next sleep or restart, because pullMayRun is asked only when a deploy or a wake starts. Listen for pull.reviewed with state changes_requested, and tear the preview down if pullMayRun now refuses its served commit.

Test both, with a writer's and the crew's running previews left alone.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs