Skip to content

fix(environment): prioritize --service-config flags over auto-detected stdin in get_edit_config - #1045

Open
AmariahAK wants to merge 1 commit into
railwayapp:masterfrom
AmariahAK:master
Open

fix(environment): prioritize --service-config flags over auto-detected stdin in get_edit_config#1045
AmariahAK wants to merge 1 commit into
railwayapp:masterfrom
AmariahAK:master

Conversation

@AmariahAK

Copy link
Copy Markdown

Description

What was the issue?

railway environment edit --service-config <SERVICE> <PATH> <VALUE> silently discards the --service-config flags and exits 0 whenever stdin is not a TTY (scripts, CI, agent harnesses, or < /dev/null). No changes are committed, and in the default output mode nothing is printed — the command appears to succeed but does nothing.

Where was the issue?

src/commands/environment/edit.rs — the get_edit_config function checked !stdin_is_terminal before has_cli_flags. When stdin was non-TTY (even empty), it short-circuited into read_config_from_stdin, which returned an empty EnvironmentConfig::default(). The explicitly passed CLI flags were never reached.

Additionally, the empty-config early-return only printed "No changes to apply" when --json or an interactive TTY was active. Non-TTY, non-JSON callers got silence and exit code 0.

How was it fixed?

Two changes in get_edit_config:

  1. Reordered the priority checks — moved has_cli_flags (explicit --service-config / --service-variable flags) to Priority 1, above the !stdin_is_terminal auto-detection block. Explicit user intent always wins over environment detection.
  2. Added an eprintln! fallback — when the resulting config is empty and neither --json nor an interactive TTY is active, "No changes to apply" now prints to stderr so scripted callers can detect the no-op.

Why this approach?

  • Matches user intent: someone passing --service-config meant to use it — the absence of a TTY shouldn't override that.
  • Matches existing codebase patterns: the sibling function edit_services_select in new.rs already checks CLI flags first, then terminal state. get_edit_config was the outlier.
  • Minimal diff: two blocks reordered, two lines added. No new functions, no new logic, no structural changes. Zero risk of breaking existing stdin JSON piping or interactive flows.

How to test locally

# Build
cargo build

# Reproduction (should have been broken — flags discarded, no change saved)
echo "" | ./target/debug/railway environment edit \
    --environment production \
    --service-config <SERVICE> deploy.preDeployCommand "echo fixed" \
    --stage --json

# Verify the change was staged
railway environment config --environment production --json

# Regression: piping JSON via stdin must still work
echo '{"services":{"<service-id>":{"deploy":{"preDeployCommand":"from-stdin"}}}}' | \
    ./target/debug/railway environment edit --environment production --stage --json

# Regression: interactive mode must still work
./target/debug/railway environment edit --environment production

Fixes #1044

Original issue: #1044

…t_edit_config

Explicit --service-config and --service-variable flags now take priority
over the stdin auto-detection path, so non-TTY environments (scripts, CI)
that pass flags plus empty/redirected stdin no longer silently discard them.

Also print 'No changes to apply' to stderr in non-TTY non-JSON mode so
scripted callers can detect the no-op instead of getting silence.

Fixes railwayapp#1044

Co-authored-by: atlarix-agent <agent@atlarix.dev>
@AmariahAK

Copy link
Copy Markdown
Author

@codyde — could you add the release/patch label to this PR? I don't have permission as a fork contributor. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

environment edit silently ignores --service-config flags when stdin is not a TTY (exit 0, nothing saved)

1 participant