Skip to content

fix(add): don't fail after service creation when project context is env-injected#1015

Open
coffee-cup wants to merge 2 commits into
masterfrom
jr/fix-add-env-context
Open

fix(add): don't fail after service creation when project context is env-injected#1015
coffee-cup wants to merge 2 commits into
masterfrom
jr/fix-add-env-context

Conversation

@coffee-cup

Copy link
Copy Markdown
Contributor

Problem

Inside a Railway Cloud Agent VM (or any env with RAILWAY_PROJECT_ID/RAILWAY_ENVIRONMENT_ID/RAILWAY_TOKEN targeting and no on-disk link), railway add --service <name>:

  1. resolves project context from env vars ✓
  2. serviceCreate mutation succeeds — the service exists now
  3. configs.link_service()get_linked_project_mut() only reads the on-disk ~/.railway config, finds no entry for cwd → Project not found. Run railway link
  4. exits nonzero without ever printing the created {id, name}

Callers (CI scripts, cloud agents) see a failure, never learn the new service id, and improvise — in the observed case, an agent deployed to a preexisting service instead of the one it had just created.

Fix

  • add: report the created service (JSON / spinner) before local-link bookkeeping, and skip linking entirely when project targeting is env-injected — there is no on-disk entry to update. Spinner only claims "and linked to it" when it actually links.
  • deploy fetch_and_create (used by railway add --database and template deploys): same shape, same skip for the post-create auto-link.
  • config: name the predicate uses_env_project_targeting() and reuse it in get_closest_linked_project_directory, which already special-cased the identical condition.

up.rs's post-create link_service is safe as-is: that flow disk-links the project via link_project before linking the service.

Verification

  • cargo test: 451 passed
  • cargo clippy --all-targets: same 44 pre-existing warnings as master, none new

…nv-injected

railway add resolved RAILWAY_PROJECT_ID/RAILWAY_ENVIRONMENT_ID for the
serviceCreate mutation, then errored in link_service because there is no
on-disk link entry to update in that mode. The service was created but the
CLI exited nonzero without ever printing the new service id, so callers
(CI, cloud agents) treated creation as failed and picked wrong targets.

- add: print the created {id, name} before local-link bookkeeping and skip
  linking entirely under env-var/token targeting
- deploy fetch_and_create: same skip for the post-create auto-link
- config: name the predicate (uses_env_project_targeting) and reuse it in
  get_closest_linked_project_directory

Claude-Session: https://claude.ai/code/session_01LPDihPsFce5vyxdbNGvV8S
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.

1 participant