12 days ago
Hello,
Two metadata read attempts using Railway CLI 5.49.6 ended with exit code 1. The latest attempt was on September 23, 2026 at 16:54:12.207896 UTC.
Invocation: railway api --file METADATA.graphql --variables @METADATA.variables.json --compact
Query shape, identifier omitted:
deployment(id: $id) { id projectId environmentId serviceId status deploymentStopped instances { id status } }
The raw output was discarded by our local wrapper, and we did not retain a provider request identifier. We therefore cannot determine whether the failure came from authentication, permissions, transport, or another cause. UNCLASSIFIED is our wrapper's classification, not a Railway error.
Status and deployment-list reads succeeded on the same day through a separate Railway connector; this does not establish that the CLI uses the same identity or permissions. The options used match its local help.
What minimal non-secret observation would you recommend to make this diagnosis actionable? We are not requesting any changes to permissions, accounts, credentials, resources, or data.
Thank you.
3 Replies
12 days ago
The most useful single observation is the response body itself. railway api exits with code 1 when the API returns a non-2xx HTTP status or when the response has a GraphQL errors array, and it prints the response body in both cases. So if your wrapper keeps stdout/stderr on the next run, the errors[].message (or the HTTP failure) will tell you whether this is authentication, permissions, or something else.
To keep the exit code from muddying that, you can add --allow-errors. With it, a GraphQL error response exits successfully and your wrapper can read the errors array directly. A non-zero exit that still happens with --allow-errors set points to an HTTP-level or transport failure rather than a GraphQL error.
The command also needs the CLI to be authenticated, either through railway login or a token. Recording which of the two was active for that run, without the token value, separates a CLI identity mismatch from a problem with the query. See the railway api docs for the flags.
Status changed to Awaiting User Response Railway • 12 days ago
12 days ago
Thank you. The latest bounded capture produced the following diagnostic:
- Railway CLI: 5.49.6
- Observation time: 23 September 2026, 22:27 UTC
- GraphQL error code: INTERNAL_SERVER_ERROR
- GraphQL error location: line 2, column 3
Could a Railway support representative review this and identify the minimum additional non-secret evidence needed to investigate the error?
Status changed to Awaiting Railway Response Railway • 12 days ago
12 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 12 days ago
12 days ago
please try running the query again with --allow-errors and provide the response here. also, if you try with a simpler query, say, just selecting the id from the deployment, does this error persist?
how are you authenticating the cli? are you logged in, or using environment variables?