fix: give acquiring runners the config the manager loop runs with

[alongubkin]

Problem

When the manager starts an update and alien deploy takes the lease and finishes it, every container is rolled twice. The second rollout uses a different spec: the containers lose ALIEN_DEPLOYMENT_ID and ALIEN_DEPLOYMENT_NAME, and command-enabled containers and daemons also lose ALIEN_COMMANDS_*. They run without these variables until the manager runs another update.

For a single-replica database, that means two restarts back to back instead of one.

Root cause

Two runners built two different configs for the same operation:

• Manager loop (loops/deployment.rs): builds an environment snapshot with the deployment id and name, the command receiver variables, and the deployment's own variables. It puts that snapshot in the config before it runs a step.
• POST /v1/sync/acquire (routes/sync.rs): returned the record's raw deploymentConfig, so the control plane's copy of the variables went out without the manager's snapshot. In standalone mode it returned no config at all.
• alien deploy and alien-deploy-cli up: both use the acquired config as-is (since fix(cli): hydrate acquired deployment configuration #380).

The executor sees a different desired config after the first rollout is ready, so it runs a second update.

The variables were not left out on purpose. Acquire already hands out the secret-bearing config: the record field is skip_serializing precisely so that acquire is the one route that returns it, and the acquire helper's doc says it exists for config fields redacted from GET /v1/deployments. Every value in the snapshot comes from data the caller already has, or is entitled to:

• the deployment id and name;
• the commands token, which is the deployment token the CLI is already authenticated with;
• the deployment's variables, which are already on the acquired record.

A runner has to write all of these into the workloads anyway.

Fix

One shared builder, RunnerConfigSources::deployment_config, used by both the loop and the acquire route. It holds the code the loop already ran, moved out unchanged: the environment snapshot, the management config, monitoring, the native image host, and how a control plane's config gets merged. Target-stack resolution (supplied stack or release stack) moves into target_release_stack, which both paths also share.

• Acquire now returns the config the loop would run with, in both platform and standalone mode. Neither CLI needed a change.
• The BYO Horizon env-var bridge stays loop-only. Its management token belongs to the manager process, and handing it out to every acquirer would be a new exposure.
• If the config can't be built (for example, a command-enabled resource with no deployment token), acquire releases the leases it just took and returns the error. Otherwise the caller would hold a lease it doesn't know about, and the manager would be blocked until it expired.
• Small cleanup: a missing stack_settings is now an error rather than a panic. The tautological with_environment_snapshot test is replaced with one that runs the real builder.

Proof

• tests/acquire_runner_config.rs: runs the CLI's real acquire helper (acquire_deployment_with_payload) against the real /v1/sync/acquire route over TCP, using sqlite stores. The deployment has an update queued to a release with a command-enabled container. The test decodes deploymentConfig the way alien deploy does and asserts the exact variable list: id, name, the four command variables scoped to the container, and the user variable.
  • Fails on main (no deploymentConfig in the response) and passes with the fix.
  • A second test checks that a config that can't be built fails the acquire with COMMAND_TOKEN_MISSING and leaves the deployment unlocked.
• routes::sync::tests::acquired_config_is_the_config_the_manager_loop_runs_with: the reported case, where a control plane supplies the config and stacks. The acquired deploymentConfig equals the loop's config field for field; only the snapshot's createdAt may differ.
• loops::deployment::tests::runner_config_replaces_control_plane_snapshot_with_manager_variables: the builder replaces the control plane's snapshot with the manager's variables.

Run in a remote sandbox (nightly-2026-10-03):

• cargo nextest run -p alien-manager --lib --test acquire_runner_config: 334 passed, including the 4 new tests.
• Same integration test with crates/alien-manager/src from main: both tests fail (acquire returns the config to run with panics because deploymentConfig is missing; the lease test fails because the acquire succeeds).
• cargo clippy -p alien-manager --tests: no warnings in the changed files.

🤖 Generated with Claude Code

[enclave-ai]

Enclave skipped this draft pull request. It will run automatically when you mark the PR as Ready for review.

[alongubkin]

@greptileai review

[greptile-apps]

Confidence Score: 5/5

[High impact] The PR appears safe to merge; no blocking issue remains.

Summary

The manager loop and acquiring runners now share RunnerConfigSources::deployment_config and target-stack lookup.

• Acquiring runners get the manager's deployment config.
• Compute-planner test fixtures now set the encryption key.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  Record[Deployment record] --> Stack[Shared target-stack lookup]
  Stack --> Builder[Shared runner-config builder]
  Builder --> Loop[Manager loop]
  Builder --> Acquire[Acquire response]
  Acquire --> Runner[CLI runner]
  Builder -->|Config build fails during acquire| Rollback[Return leases and restore retry requests]

Loading

_{Reviews (4) · Last reviewed commit: "test: set encryption_key in the compute ..." · Reviewed by Greptile}

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review