a month ago
We are trying to verify, in a read-only way, that all processes capable of accessing a Volume-backed service have terminated before starting a scheduled data collection job.
Using Railway's API, environment.deployments returned hasNextPage=false, but it did not include a previous REMOVED deployment that was still retrievable directly by deployment ID.
We confirmed:
The current deployment has a RUNNING instance.
The immediately previous deployment's instance is REMOVED and deploymentStopped=true.
We are not trying to modify deployment state or database records; we only need to understand the scope and guarantees of Railway's read APIs.
Could you clarify:
What are the default filters and retention scope of environment.deployments? Is there a supported API/query that reliably enumerates all currently running or terminating deployments/instances for a service?
For a service with a Railway Volume attached, does Railway's single-active-mount protection guarantee that processes from a previous deployment or one-off execution can no longer access the Volume before a new deployment becomes active? Please distinguish Volume unmounting from process termination if they are separate.
Without changing configuration or restarting the service, what is the recommended read-only method to verify all current execution actors/instances and their termination state?
We are not asking Railway to determine whether our application-level collection job completed, and we are not requesting any database changes. We only want to understand the platform-level observability and guarantees.
Pinned Solution
a month ago
I'm pretty sure you can always retrieve a deployment by it's ID (using the deployment query and specifying an ID), regardless of the status it is in. The Environment.deployments will return deployments that are currently running, failed, removing, or crashed — so a REMOVED deployment dropping out of that list is expected rather than a gap. If you want the history in a list instead of fetching by ID, the top-level deployments(input: DeploymentListInput!) query takes an includeDeleted flag.
For any service with a volume, no 2 deployments can run at the same time. Only a single deployment can be mounted to the volume at once (which means you may see downtime inbetween deployments).
Also, the unmount doesn't happen until the teardown, which happens after the SIGKILL has been sent to the container. The flow is SIGTERM, then the draining window (which can be configured via RAILWAY_DEPLOYMENT_DRAINING_SECONDS, defaulting to 0), then SIGKILL. Note that the variable RAILWAY_DEPLOYMENT_OVERLAP_SECONDS is a no-op here.
One thing to watch out for given you're running a scheduled job: cron executions aren't automatically terminated. If a previous execution is still running, it keeps its container and its mount, and the next scheduled run gets skipped rather than queued.
To my knowledge, there is no read-only way to find what deployment currently holds the mount to the volume. You could potentially create an in-volume lock file — write RAILWAY_DEPLOYMENT_ID to a file on the mount from your start command and hold an flock on it, if necessary.
3 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
You could use the Deployments query to fetch all deployments and filter based on their status for if they are running/removed
milo
You could use the Deployments query to fetch all deployments and filter based on their status for if they are running/removed
a month ago
Thanks. We have already queried deployments and filtered by status.
The issue is that environment.deployments returned hasNextPage=false, while a previous REMOVED deployment was still retrievable directly by its deployment ID but was not present in that list.
Could you clarify whether the Deployments query is guaranteed to enumerate all currently RUNNING or terminating deployment instances, even if historical REMOVED deployments may be omitted?
Also, could you clarify the Volume behavior from questions 2 and 3 above — specifically whether a previous deployment or one-off execution can still access the same Volume after a new deployment becomes active, and what Railway recommends as the read-only way to verify all currently active execution actors for a Volume-backed service?
a month ago
I'm pretty sure you can always retrieve a deployment by it's ID (using the deployment query and specifying an ID), regardless of the status it is in. The Environment.deployments will return deployments that are currently running, failed, removing, or crashed — so a REMOVED deployment dropping out of that list is expected rather than a gap. If you want the history in a list instead of fetching by ID, the top-level deployments(input: DeploymentListInput!) query takes an includeDeleted flag.
For any service with a volume, no 2 deployments can run at the same time. Only a single deployment can be mounted to the volume at once (which means you may see downtime inbetween deployments).
Also, the unmount doesn't happen until the teardown, which happens after the SIGKILL has been sent to the container. The flow is SIGTERM, then the draining window (which can be configured via RAILWAY_DEPLOYMENT_DRAINING_SECONDS, defaulting to 0), then SIGKILL. Note that the variable RAILWAY_DEPLOYMENT_OVERLAP_SECONDS is a no-op here.
One thing to watch out for given you're running a scheduled job: cron executions aren't automatically terminated. If a previous execution is still running, it keeps its container and its mount, and the next scheduled run gets skipped rather than queued.
To my knowledge, there is no read-only way to find what deployment currently holds the mount to the volume. You could potentially create an in-volume lock file — write RAILWAY_DEPLOYMENT_ID to a file on the mount from your start command and hold an flock on it, if necessary.
Status changed to Solved 0x5b62656e5d • about 1 month ago