i think the problem is that environmentId isn't marked as required in the schema even though it totally should be. so the mutation accepts your request, probably tries to do something with it, fails internally, but still returns success. super annoying for the terraform provider obviously

needs to make environmentId actually required in the schema:

input VolumeCreateInput {
  projectId: String!
  environmentId: String!  # this needs the ! 
  mountPath: String!
  name: String
}

the breaking change impact is minimal because any code that's currently working already has the environmentId in there. you're only "breaking" code that was already silently failing

I actually don't entirely agree. The schema for volumeCreateInput says the following: "The environment to deploy the volume instances into. If null, the volume will not be deployed to any environment. undefined will deploy to all environments." which is a fine behaviour but both omitting the value (which I think is equivalent to undefined) and explicit null seem to do the same which is not deploy to any environment. Hence, this is also not consistent with serviceCreate.

ok i m reading the documentation

I am the author of the terraform provider. Stop using AI slop to answer. Terraform providers don't have a backend and are not written in JS.

Both serviceCreate and volumeCreate have the same documentation of differences between null and undefined. But something seemed to change on railway side regarding volumeCreate and we would like to ask the railway people what changed and what's the plan for the future and to update the documentation of the API accordingly if needed.

So, please stop messing up the thread with your stupid fucking AI answers without even understanding the context of the question.

i was trying to help but i didnt use AI as you assume, i clearly missed the actual context here, sorry for cluttering the thread

Hi, you should specify a environmentId if you want to create the volume instance in the environment. Otherwise it will just create the volume concept. So you can make a staged changes patch of the volume instance creation for the environment.

Hey paulo, how do we create volume instances in all environments? That was what previous undefined was doing.

Do we have to manually do that?

May you clarify the use-case? This was causing unsafe edge-cases that we want to avoid.

It's for the terraform provider as linked in the original post. Due to how railway API used to behave, when user creates a volume, the provider assumes it's created in all environments. That is how the provider is implemented. And this is how serviceCreate works too.

Changing the volumeCreate behaviour without changing the serviceCreate behaviour will lead to unsafe edge-cases in the terraform provider.

I see, I will work on allowing that edge-case without risk. But could you clarify why is that behavior the case? Why do you need to deploy to all environments?

And can we avoid that behavior moving forward?

And can we avoid that behavior moving forward?

Actually, we can avoid that behavior without needing to deploy volumeInstance to all environments if you change how serviceCreate works.

We need to deploy volumeInstance to all environments because the serviceInstance is being deployed to all environments.

Interesting, so it's to ensure there is feature parity. Ok, I will restore that volumeInstance behavior. Sadly some systems depend on that serviceInstance bahavior, we have tried to change it before.

Sorry for that experience.

I merged a fix. Can you try to reproduce this again please? It should be restored now, but I want to ensure it supports your use-case specifically.

That fixed it, thanks!