Skip to content

fix: provider-honest compute suspend help copy #162

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tonychang04 wants to merge 3 commits into
base: main
Choose a base branch
from
+1 −1
Open

fix: provider-honest compute suspend help copy #162

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
876bddb
fix: provider-honest `compute suspend` help copy
tonychang04 Aug 31, 2026
cf823f7
fix: make suspend copy honest on both compute planes
tonychang04 Aug 31, 2026
8af2795
fix: drop the false disk-durability promise from suspend copy
tonychang04 Aug 31, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/index.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -227,7 +227,7 @@ compute.command('start [service]').description('Bring a compute service online (
.option('--json').option('--branch <branch>', 'branch (default: current)').action(guard((service, o) => computeCmd.computeStart(service, o)))
compute.command('stop [service]').description('Take a compute service offline; traffic will NOT wake it until `start`')
.option('--json').option('--branch <branch>', 'branch (default: current)').action(guard((service, o) => computeCmd.computeStop(service, o)))
compute.command('suspend [service]').description('Suspend a compute service (RAM snapshot); stays down until `start`')
compute.command('suspend [service]').description('Suspend a compute service: takes the machine down until `start` — do not rely on in-memory or on-disk state surviving (a service with a /data volume cannot be suspended; use `stop`)')

@cubic-dev-ai cubic-dev-ai Bot Aug 31, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: The copy now errs on the opposite plane from the claim it replaces. 'do not rely on in-memory or on-disk state surviving' is accurate for insta-compute (per the reviewer note that disk state doesn't persist there), but a false warning for legacy Fly-backed services, which per the PR description still get memory-snapshot suspend with persistent disk state. Since the PR's goal is copy that promises only what both planes deliver, stating that neither in-memory nor on-disk state survives still isn't plane-neutral — it swaps the falsehood from the insta-compute plane to the Fly plane. Keep the wording to the common denominator (the machine is down until start) and drop the blanket state-survival claim, or scope it explicitly to insta-compute.

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At src/index.ts, line 230:

<comment>The copy now errs on the opposite plane from the claim it replaces. 'do not rely on in-memory or on-disk state surviving' is accurate for insta-compute (per the reviewer note that disk state doesn't persist there), but a false warning for legacy Fly-backed services, which per the PR description still get memory-snapshot suspend with persistent disk state. Since the PR's goal is copy that promises only what both planes deliver, stating that neither in-memory nor on-disk state survives still isn't plane-neutral — it swaps the falsehood from the insta-compute plane to the Fly plane. Keep the wording to the common denominator (the machine is down until `start`) and drop the blanket state-survival claim, or scope it explicitly to insta-compute.</comment>

<file context>
@@ -227,7 +227,7 @@ compute.command('start [service]').description('Bring a compute service online (
 compute.command('stop [service]').description('Take a compute service offline; traffic will NOT wake it until `start`')
   .option('--json').option('--branch <branch>', 'branch (default: current)').action(guard((service, o) => computeCmd.computeStop(service, o)))
-compute.command('suspend [service]').description('Suspend a compute service (releases the machine; disk state persists — do not rely on in-memory state surviving); stays down until `start`')
+compute.command('suspend [service]').description('Suspend a compute service: takes the machine down until `start` — do not rely on in-memory or on-disk state surviving (a service with a /data volume cannot be suspended; use `stop`)')
   .option('--json').option('--branch <branch>', 'branch (default: current)').action(guard((service, o) => computeCmd.computeSuspend(service, o)))
 compute.command('restart [service]').description("Restart a compute service by re-running the image it already runs against a freshly resolved env bundle — this is how a changed secret or binding reaches a running machine (env is baked into the machine at deploy time), and how a machine that is up but wedged gets cycled (`start` no-ops on one that is already started). No new image, no new spec. The service must be running: a stopped or suspended one comes back with `insta compute start`. All plans; gated: deploy — it lands configuration the same way a deploy does, so a policy denying deploys denies this too (`start`/`stop` stay ungated, and cycle a wedged machine without one). A service whose app fails to answer on its port coming back up reports that failure, and the machines are rolled back, best-effort, to the config they were serving")
</file context>
Suggested change
compute.command('suspend [service]').description('Suspend a compute service: takes the machine down until `start` — do not rely on in-memory or on-disk state surviving (a service with a /data volume cannot be suspended; use `stop`)')
compute.command('suspend [service]').description('Suspend a compute service: takes the machine down until `start` (a service with a /data volume cannot be suspended; use `stop`)')

.option('--json').option('--branch <branch>', 'branch (default: current)').action(guard((service, o) => computeCmd.computeSuspend(service, o)))
compute.command('restart [service]').description("Restart a compute service by re-running the image it already runs against a freshly resolved env bundle — this is how a changed secret or binding reaches a running machine (env is baked into the machine at deploy time), and how a machine that is up but wedged gets cycled (`start` no-ops on one that is already started). No new image, no new spec. The service must be running: a stopped or suspended one comes back with `insta compute start`. All plans; gated: deploy — it lands configuration the same way a deploy does, so a policy denying deploys denies this too (`start`/`stop` stay ungated, and cycle a wedged machine without one). A service whose app fails to answer on its port coming back up reports that failure, and the machines are rolled back, best-effort, to the config they were serving")
.option('--json').option('--branch <branch>', 'branch (default: current)').action(guard((service, o) => computeCmd.computeRestart(service, o)))
Expand Down
Loading