Mutable container ID

[cthulhu-rider]

Is your feature request related to a problem? Please describe.

with #3733, container became dynamic. We have code that relies on the container's immutability. I accidentally noticed that neofs-cli container get outputs calculated ID, not the one entered by --cid flag

$ neofs-cli container get -r s04.neofs.devenv:8080 --cid 3x43ZKRW5dfSiYiVVEXrLN3Fpdtrk336ZA74ZB24bXZq
container ID: 5nC7hN9HCDoRgFZqah12pgo4uiW9D3oh9b68sFjZuvH
owner ID: NbUgTSFvPmsRxmGeWpuuGeJUoRoi6PErcM
basic ACL: 1fbf8cff (public-read)
       RangeHASH    Range      Search     Delete     Put        Head       Get
0 1    1 1 1 1      1 0 1 1    1 1 1 1    1 0 0 0    1 1 0 0    1 1 1 1    1 1 1 1
X F    U S O B      U S O B    U S O B    U S O B    U S O B    U S O B    U S O B
  X-Sticky F-Final U-User S-System O-Others B-Bearer
created: 2026-01-28 12:07:02 +0300 MSK
attributes:
	Timestamp=1769591222
	__NEOFS__LOCK_UNTIL=1769591443
placement policy:
REP 1
CBF 1

i've collected all such cases

1. neofs-cli container get
2. neofs-cli container nodes
3. neofs-adm fschain restore-containers
4. SN responding to creation request
5. IR handling creation request
6. SN meta handling

3 works with local file and creates containers. IDs entered via cmd flag just selects which ones to create. So, it's OK

4 and 5 work w/ to-be-created container, OK

1 just makes a confusing output, but it's still worth fixing

6 calculates placement depending on CID and tunes behavior depending on container affiliation. If CID changes, placement changes. But container placement should not change overall. So, i see it is a problem

2 is similar to 6, but less harmful

Describe the solution you'd like

calculate CID only when there is no other way. Currently, it is for 4/5 naturally, and 1/2 w/ file input

[carpawell]

But container placement should not change overall. So, i see it is a problem

calculate CID only when there is no other way

I see there is confusion/conflict in these statements, there is no ID field in the containter structure so once it is changed, we lose all relations we had before (i think it is even hard to predict how many things may break in the node). I think this should be somehow fixed on the API level first of all, it has now conflicts in ID's description, struct definition and the service we provide.

[cthulhu-rider]

so once it is changed, we lose all relations we had before

there is a hard linking in the contract. So, this is not true

I think this should be somehow fixed on the API level first of all, it has now conflicts in ID's description, struct definition and the service we provide.

good point, I'll update docs

i think it is even hard to predict how many things may break in the node

the node just needs to keep (ID, container) pair everywhere. For the most part, this is how it's done

[carpawell]

so once it is changed, we lose all relations we had before

there is a hard linking in the contract. So, this is not true

I thought you mentioned situations when you have a container, but dont know its (original) ID, hard links does not work this way, otherwise everything should be ok, no? Guess it is mostly about 6. in the issue. Now i have thought about it one more time and think that it should not be possible to get into such a situation ever, CID (the original one) should always be somewhere near, i think we just need to change a few lines.

1, 2 with file input is smth strange to me and are completely broken after we allowed changing containers. I would drop it as a tool that cannot provide 100% workable functionality.

[carpawell]

I would drop it as a tool that cannot provide 100% workable functionality.

Or do not print smth we are not sure about.

[cthulhu-rider]

yes, im mainly concerned about 6

[roman-khimov]

neofs-cli container get

I'm surpised no test noticed it, but we can drop it from the output, CID is an input parameter here anyway.

neofs-cli container nodes

Same.

neofs-adm fschain restore-containers

Should be extended with CID, although I doubt anyone ever used the feature at all.

SN responding to creation request

Should match the expectation, easy to ensure that.

IR handling creation request

Same.

SN meta handling

It knows the ID and knows corresponding node lists, it shouldn't care much about other things, especially calculating ID from binary.

i think it is even hard to predict how many things may break in the node

We have all of our test suite running fine, so not a big issue to me. There is almost never a case where CID isn't known and we need to derive it from binary.

[roman-khimov]

neofs-adm fschain restore-containers

Should be extended with CID, although I doubt anyone ever used the feature at all.

I mean

// Container represents container struct in contract storage.                                                                                                                                                                                                                                                                                                                                
type Container struct {
        Value     []byte `json:"value"`
        Signature []byte `json:"signature"`
        PublicKey []byte `json:"public_key"`
        Token     []byte `json:"token"`
        EACL      *EACL  `json:"eacl"`
}

is already outdated in many ways, but adding a CID here completely solves this particular problem.