fix(status): dispatch to remote host like health does - #505
Merged
gfargo-horizon-agent[bot] merged 2 commits intoAug 2, 2026
Merged
Conversation
cmd_status differed from cmd_health in two ways that broke the MCP strut_status tool for stacks resolved purely through strut.conf [stacks]/[hosts] topology (no base per-env file on disk): - validate_env_file was called unconditionally, so a missing env file hard-failed status instead of falling through to should_dispatch_remote the way health does. - the remote dispatch branch didn't forward --json, so a remote status call (which the MCP tool always requests) silently dropped the flag. Both are now handled the same way cmd_health already does it.
The previous fix for cmd_status skipped validate_env_file whenever the env file didn't exist, which silently let a local run through even when --env pointed at a typo'd/nonexistent name (broke tests/test_cli_env_parsing.bats). Move validate_env_file back so it's only skipped ahead of the should_dispatch_remote check (needed for a topology-only stack with no base per-env file), and still runs unconditionally once we know we're staying local.
![gfargo-horizon-agent[bot]](https://avatars.githubusercontent.com/in/4083186?s=60&v=4){kind=small}
Contributor
Author
There was a problem hiding this comment.
🔎 Agent review (sonnet) — LGTM
REVIEW: LGTM
RESOLVES: full
The PR closes the two remaining asymmetries between cmd_status and cmd_health (env-file validation ordering and --json forwarding on remote dispatch), verified by tracing should_dispatch_remote/topology_apply_to_env to confirm VPS_HOST is already exported by the entrypoint before cmd_status runs, so moving validate_env_file after the dispatch check is safe. Tests are updated to match the new tolerant behavior and add explicit --json-forwarding coverage.
gfargo-horizon-agent
Bot
deleted the
agent/strut-2256-strut-501-mcp-strut-status-queries-local
branch
August 2, 2026 17:47
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
cmd_statusandcmd_healthshare the same remote-dispatch mechanism (should_dispatch_remote/run_remote_strut), butcmd_statushad two asymmetries that could leave a topology-mapped stack querying the local Docker daemon instead of the VPS, and that would silently drop--jsonwhen it did dispatch remotely — both directly affecting thestrut_statusMCP tool, which always requests--json.Why
Closes #501
Plane: OSS-2256
How
cmd_statusnow guardsvalidate_env_filewith a-fcheck, matchingcmd_health. A stack resolved purely throughstrut.conf[stacks]/[hosts]topology (VPS_HOST supplied by topology, no base per-env file on disk) is a valid config for a read-only command — it shouldn't hard-fail with "Env file not found" before ever reachingshould_dispatch_remote.cmd_status's remote-dispatch branch now forwards--jsonto the SSH'd invocation, matchingcmd_health. Previously the flag was silently dropped, so a remotestrut_status --jsoncall returned the SSH session's raw output instead of what the caller asked for.tests/test_cmd_status_remote.bats: replaced the old "fails gracefully when env file missing" test (which asserted the hard-fail) with tests asserting the new tolerant behavior (dispatches to SSH whenVPS_HOSTis set even without an env file; falls back to local when it isn't), plus a new test asserting--jsonis forwarded on remote dispatch.Testing
cmd_status/cmd_healthend-to-end against a synthetic project withstrut.conf[hosts]/[stacks]topology and a stubbedssh, confirming status now dispatches remotely (with--jsonforwarded) both with and without a base.prod.envfile present.bats tests/— not runnable in this sandbox (nobats/shellcheckavailable); relying on CI.🤖 Generated by the harbor agent loop. Reviewed by a human before merge.
Closes #501