How to make sure Volume is attached immediately a Service Starts - Railway Help Station

How to make sure Volume is attached immediately a Service Starts

3 months ago

I am currently having an issue with a race condition where I create a service and a volume after that, but because the service image was run before the volume was created persistent storage doesnt happen until a restart of the deployment.

I am currently using the API to create services and volumes.

I have also tried creating the service, then the volume, then removing the deployment and restarting it all sequentially, this doesnt work either. I have to remove and redeploy the service deployment after its completed the first time, only then does the volume work.

Solved$30 Bounty

62 Replies

3 months ago

Hey, maybe you can create a service and remove the deployment right after? Can I know what mutations are you using?

3 months ago

mutation ServiceCreate($input: ServiceCreateInput!) {
  serviceCreate(input: $input) {
    id
    name
    icon
    createdAt
    updatedAt
    project {
      baseEnvironmentId
      environments {
        edges {
          node {
            deployments(first: 1) {
              edges {
                node {
                  id
                  status
                }
              }
            }
          }
        }
      }
    }
  }
}

Service Create

3 months ago

mutation VolumeCreate($projectId: String!, $environmentId: String!, $serviceId: String!, $mountPath: String!, $region: String!) {
  volumeCreate(
    input: {projectId: $projectId, environmentId: $environmentId, serviceId: $serviceId, mountPath: $mountPath, region: $region}
  ) {
    id
    name
    createdAt
  }
}

Then Volume Create

3 months ago

In this order, the first deplyoment isnt persisted

3 months ago

Then I added a

mutation DeploymentRemove($id: String!) {
    deploymentRemove(id: $id)
}


mutation DeploymentRedeploy($id: String!) {
  deploymentRedeploy(id: $id) {
    id
    status
    createdAt
  }
}

So that this runs immediately after volume creation, but it didnt seem to work either (the first deployment wast removed and redployed)

3 months ago

Sorry, missed the last part of your message, so basically when you try to remove the initial deployment, nothing happens?

3 months ago

yeah

3 months ago

Will give it a test, give me a minute.

3 months ago

I see another way of doing this, create an empty service (with no source), attach volume and then call serviceInstanceUpdate with your source.

3 months ago

Thats actually not bad

3 months ago

That eliminates the need for the deployments relation and all of the deployments call

3 months ago

Let me give it a go

3 months ago

i think i am meant to run something else after this, to actually get the deployment started

3 months ago

Maybe serviceInstanceRedeploy should do the trick

3 months ago

im about to try DeployV2

3 months ago

if that doesnt work ill go redeploy

3 months ago

Great, looks like the dashboard uses serviceInstanceDeploy

1446979043504427300

3 months ago

love the help and effort with the debugging man!

3 months ago

thank you so much

3 months ago

moment of truth

3 months ago

wtf, it just stopped

3 months ago

after deploying lol

3 months ago

Stopped?

3 months ago

yeah

3 months ago

What do you mean? the deployment stopped?

3 months ago

Like removed

3 months ago

I think i know why give me a second, to try again

3 months ago

IT WORKS

3 months ago

Ig there is just one more thing, I manually set the region on the service update, etc

3 months ago

But now I get this always on the service

1446981962974630100

3 months ago

https://tenor.com/view/zonegif-pandlr-pandlrg-pandlrgif-stan-twitter-gif-17205990219167042856

3 months ago

https://tenor.com/view/neymar-sheozinho-gif-12596032940904998920

3 months ago

Maybe the volume or service are in different regions?

3 months ago

i set them up to be the same

3 months ago

After creating the empty service I do this

mutation UpdateRegions($environmentId: String!, $serviceId: String!, $multiRegionConfig: JSON!) {
  serviceInstanceUpdate(
    environmentId: $environmentId
    serviceId: $serviceId
    input: {multiRegionConfig: $multiRegionConfig}
  )
}

Set it to EU

3 months ago

Create the Volume, in EU

3 months ago

Then do this new flow

mutation serviceInstanceUpdateAndDeploy($environmentId: String!, $serviceId: String!, $image: String!, $region: String!) {
  serviceInstanceUpdate(input: {source: {image: $image}, region: $region}, serviceId: $serviceId)
  serviceInstanceDeployV2(environmentId: $environmentId, serviceId: $serviceId)
}

Setting EU as well

3 months ago

wtf, the deployment is removed now lol

3 months ago

time for more tests, give me a minute again

3 months ago

dont worry about this, its because the system was off

3 months ago

Just a guess but maybe try serviceInstanceDeploy?

3 months ago

"lastCommit": true works for images too

3 months ago

will do next, rn im switching the possitions of the calls

EmptyServiceCreate
UpdateServiceInstanceRegionOnly
Create Volume in same region
Update service adding image and deploying after

3 months ago

Doesnt work

3 months ago

ill try this now

3 months ago

Also, I see that you're using $region here, maybe continue with $multiRegionConfig?

3 months ago

Yeah

3 months ago

trying

3 months ago

nshh

3 months ago

donest work

3 months ago

this is weird

3 months ago

For some reason it migrates the Volume to US East

3 months ago

The only reason I can see here for this is that Railway is using some kind of default region, maybe try updating the preferred region? Not a fix but can help us debug a little bit more

1446987648983105500

3 months ago

Yeah isnt, because I want dynamic regions

3 months ago

this worked before when I didnt have volumes

3 months ago

But now with volumes its broken

3 months ago

I had no problems following what you did

1446992846358839300

3 months ago

Here's what I did:

ServiceCreate:

mutation ServiceCreate($input: ServiceCreateInput!) {
  serviceCreate(input: $input) {
    id
    name
    icon
    createdAt
    updatedAt
  }
}

{
  "input": {
    "name": "teste",
    "projectId":"40f983b6-e729-4f32-be47-346ef7d5a9c0"
  }
}

ServiceInstanceUpdate:

mutation update($config: JSON!) {
  serviceInstanceUpdate(
    environmentId: "55bc433f-96d0-4415-9814-cacf9bd1e475"
    serviceId: "cfa44c0c-3f88-4a16-a465-998286082d8a"
    input: {multiRegionConfig: $config, source: {image: "hello-world"}}
  )
}

{
  "config": {
    "us-east4-eqdc4a": null,
    "europe-west4-drams3a": {
      "numReplicas": 1
    }
  }
}

VolumeCreate:

mutation VolumeCreate($projectId: String!, $environmentId: String!, $serviceId: String!, $mountPath: String!, $region: String!) {
  volumeCreate(
    input: {projectId: $projectId, environmentId: $environmentId, serviceId: $serviceId, mountPath: $mountPath, region: $region}
  ) {
    id
    name
    createdAt
  }
}

{
  "projectId": "40f983b6-e729-4f32-be47-346ef7d5a9c0",
  "environmentId": "55bc433f-96d0-4415-9814-cacf9bd1e475",
  "serviceId": "cfa44c0c-3f88-4a16-a465-998286082d8a",
  "mountPath": "/data",
  "region": "europe-west4-drams3a"
}

ServiceDeploy:

mutation {
  serviceInstanceDeploy(
    latestCommit: true
    serviceId: "cfa44c0c-3f88-4a16-a465-998286082d8a"
    environmentId: "55bc433f-96d0-4415-9814-cacf9bd1e475"
  )
}

3 months ago

Hmm you are forcing null on us east

3 months ago

I’ll try

3 months ago

It works

3 months ago

You are a life saver

Status changed to Solved brody • 3 months ago