fix: do not allocate if blob is already stored#678
Conversation
| result: { error: /** @type {{}} */ (new Error()) }, | ||
| }) | ||
| : await generateAcceptReceipt(blobPutTask.cid.toString()) | ||
| const blobConcludePut = await createConcludeInvocation( |
There was a problem hiding this comment.
This was just copy pasta error and wrong. If hasHttpPutReceipt was false then we'd get an errored receipt anyway and if it was true it would add a blob accept receipt 🤦♂️
|
Couldn't we just behave the same way as if we happened to pick a node where it was already uploaded? In fact, we could specifically "allocate" on a node where it's already been uploaded, and everything should flow from there, no? |
| console.error( | ||
| 'fetching %s receipt for task: %s: %o', | ||
| t.capabilities[0].can, | ||
| t.cid, | ||
| rcptRes.error | ||
| ) |
You could, it assumes the original upload node still exists or the handler has access to the current location(s) of the blob in the case that it does not. i.e. not just the fact that the blob is registered in the space. I know we don't have provision yet for repair when failures happen or when nodes leave the network but when we do it feels simplier to keep the scope of what the upload flow needs to know small and hence the current location of a blob as a separate concern. What I mean is that when we do implement repair, I'd like to not touch the upload flow. If the upload flow needs to know the current location so that it can issue an allocation on the same node then we'll need to change the upload flow to consider that, or we'll likely just forget and find a bug later. To summarise, I'd like to keep the process of onboarding a blob and managing it's current location separate if possible. Allocating again on the same node couples these processes. |
|
I like that. I wasn't considering that Piri will also (I think) return no |
…9.100, @storacha/ui-core@2.4.163, @storacha/upload-client@1.4.1, @storacha/client@2.1.1, @storacha/upload-api@3.2.1, @storacha/cli@2.1.1 (#684) ## @storacha/encrypt-upload-client@1.1.80 (2026-03-04) ### 🧱 Updated Dependencies - Updated @storacha/upload-client to 1.4.1 - Updated @storacha/client to 2.1.1 ## @storacha/ui-react@2.9.100 (2026-03-04) ### 🧱 Updated Dependencies - Updated @storacha/encrypt-upload-client to 1.1.80 - Updated @storacha/ui-core to 2.4.163 ## @storacha/ui-core@2.4.163 (2026-03-04) ### 🧱 Updated Dependencies - Updated @storacha/client to 2.1.1 ## @storacha/upload-client@1.4.1 (2026-03-04) ### 🩹 Fixes - fix: do not allocate if blob is already stored ([#678](#678)) ### ❤️ Thank You - ash ## @storacha/client@2.1.1 (2026-03-04) ### 🧱 Updated Dependencies - Updated @storacha/upload-client to 1.4.1 - Updated @storacha/upload-api to 3.2.1 ## @storacha/upload-api@3.2.1 (2026-03-04) ### 🩹 Fixes - fix: do not allocate if blob is already stored ([#678](#678)) ### ❤️ Thank You - ash ## @storacha/cli@2.1.1 (2026-03-04) ### 🧱 Updated Dependencies - Updated @storacha/client to 2.1.1 - Updated @storacha/upload-api to 3.2.1 Co-authored-by: Rachabot <rachabot@storacha.network>
3 participants
If the blob is already successfully stored in the space, do not allocate again on a (potentially) new node.
The subtle change here is that when attempting to store a blob that has already been stored you receive the original allocation from the successful upload.
It means that there may be an
address(URL to PUT to) in the allocation receipt. If there is, you ALSO need to check for ahttp/putreceipt - because if it exists, then the blob was uploaded previously and you do not need to upload it again.