Summary
When a project has more than one deployment (e.g. one to a cloud server, one to an existing server), running stacker agent status and stacker agent health without --deployment can resolve to different "active" deployments for the same project, giving contradictory results in the same session.
Steps to reproduce
- Deploy the same project twice to different targets, e.g.:
stacker deploy --target server --watch # deployment A
stacker deploy --target cloud --key htz-0 --force-new --watch # deployment B
- Run
stacker agent status (no --deployment flag). Note the deployment hash it auto-selects (printed as "using active agent for project '': ").
- Immediately run
stacker agent health (no --deployment flag). Note the deployment hash it auto-selects.
Observed
In our case (project ntfy, id=551):
stacker agent status resolved to deployment_5bac5017... (the newer, completed cloud deployment) — reported the app running correctly.
stacker agent health resolved to deployment_f27d9440... (an older, paused/broken existing-server deployment) — reported Overall: degraded, with the app container stuck in created state.
Passing --deployment <hash> explicitly to either command works correctly and both agree once resolved to the same value — the bug is only in the "no --deployment given" auto-resolution path.
Expected
Both commands should apply the same "pick the active deployment for this project" rule (e.g. most recent, or most recently successful/non-paused), so status and health never disagree about which deployment they're describing.
Impact
Confusing/contradictory output makes it hard to trust the "no flag" convenience path — a user could see health reporting "degraded" for what is actually a healthy, currently-serving deployment, because it silently picked a stale one.
Environment
- stacker CLI 0.3.1 (fbffb9e)
- Reproduced while testing
stacker-projects/ntfy in trydirect/stacker-project-examples
Summary
When a project has more than one deployment (e.g. one to a cloud server, one to an existing server), running
stacker agent statusandstacker agent healthwithout--deploymentcan resolve to different "active" deployments for the same project, giving contradictory results in the same session.Steps to reproduce
stacker agent status(no--deploymentflag). Note the deployment hash it auto-selects (printed as "using active agent for project '': ").stacker agent health(no--deploymentflag). Note the deployment hash it auto-selects.Observed
In our case (project
ntfy, id=551):stacker agent statusresolved todeployment_5bac5017...(the newer, completed cloud deployment) — reported the app running correctly.stacker agent healthresolved todeployment_f27d9440...(an older, paused/broken existing-server deployment) — reportedOverall: degraded, with the app container stuck increatedstate.Passing
--deployment <hash>explicitly to either command works correctly and both agree once resolved to the same value — the bug is only in the "no--deploymentgiven" auto-resolution path.Expected
Both commands should apply the same "pick the active deployment for this project" rule (e.g. most recent, or most recently successful/non-paused), so
statusandhealthnever disagree about which deployment they're describing.Impact
Confusing/contradictory output makes it hard to trust the "no flag" convenience path — a user could see
healthreporting "degraded" for what is actually a healthy, currently-serving deployment, because it silently picked a stale one.Environment
stacker-projects/ntfyin trydirect/stacker-project-examples