[BUG] The purchase details API returns a different CID

[2-towns]

Describe the bug When I retrieve the purchase details for a storage request, the CID returned in the content element of the json is different from the CID I used to make the storage request.

To Reproduce Steps to reproduce the behavior:

1. Upload a file and get the CID
2. Create a storage request
3. Get the storage request ID
4. Get the purchase details using the previous request ID

Expected behavior The CID should be the same as the uploaded file.

Screenshots

curl -H 'Content-Type: application/json' -d '{ "duration":"3600", "reward":"2", "proofProbability":"3", "nodes":"2", "tollerance":"0", "collateral":"10", "expiry":"900" }'  -X POST  http://localhost:8002/api/codex/v1/storage/request/zDvZRwzkvwapyNeL4mzw5gBsZvyn7x8F8Y9n4RYSC7ETBssDYpGe

# Got 0e2fcdf28e4ced6226eac57e2f5fa02fd059b4e48c557ab1bb45b233a891201b

curl http://localhost:8002/api/codex/v1/storage/purchases/0e2fcdf28e4ced6226eac57e2f5fa02fd059b4e48c557ab1bb45b233a891201b | jq

The json is :

{
  "requestId": "0x0e2fcdf28e4ced6226eac57e2f5fa02fd059b4e48c557ab1bb45b233a891201b",
  "request": {
    "client": "0x9f0c62fe60b22301751d6cde1175526b9280b965",
    "ask": {
      "slots": 2,
      "slotSize": "131072",
      "duration": "3600",
      "proofProbability": "3",
      "reward": "2",
      "collateral": "10",
      "maxSlotLoss": 0
    },
    "content": {
      "cid": "zDvZRwzkwREboCfGR3KPP9YT61nbcFRqzncmNLpognCvwMMKkPWm"
    },
    "expiry": "900",
    "nonce": "0x473413c190c1ffae5bcd7ab56c3c2e17115fd02266c90a0ec605f0c8823d1c0b",
    "id": "0x0e2fcdf28e4ced6226eac57e2f5fa02fd059b4e48c557ab1bb45b233a891201b"
  },
  "state": "submitted",
  "error": null
}

Environment:

• OS: Linux
• Version: 22
• Tag/Commit: Master
• Arch: amd64

[dryajov]

This is not a bug. When you create a storage request, the data is processed (erasure coding, slot creation) which requires a new CID to identify it. The old data is still accessible with the old CID, but for the purpose of tracking the persisted data, you need the new CID.

[AuHau]

I am wondering if it would not make sense also to store the original CID? I can see how this "CID change" can be confusing to the users. Also it somewhat "breaks" the immutability promise of content-addressing, because the CID changes...

[2-towns]

I am wondering if it would not make sense also to store the original CID? I can see how this "CID change" can be confusing to the users. Also it somewhat "breaks" the immutability promise of content-addressing, because the CID changes...

Yes definitely.

After creating the storage request on the marketplace UI, the list of purchases is refreshed. So if another CID appears for the request created, I am sure it will create some confusion for the user.

[dryajov]

I guess the reason why we didn't return the original CID is because it's needed to initiate the request in the first place. The original CID is part of the protected/verifiable manifest tho.