add space to blob/remove and define blob/unallocate capability#46
Conversation
…ities /blob/remove now carries the space explicitly, matching the Allocate/Accept convention: storage nodes key allocations and acceptances by (digest, space), and removal releases ONE space's claim — physical deletion happens only when no space claims the digest at all. Also documents who serves /blob/remove and /upload/remove, their subject conventions, and idempotency (previously the bindings carried no semantics at all). Groundwork for the delete-finality chain: piri's /blob/remove handler (FIL-623/FIL-624), sprue's remove handlers (FIL-522), and ingot's client wiring (FIL-588). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
An upload now ends in exactly one of /blob/accept (commit) or /blob/unallocate (drop). Unallocate retires a parked blob — allocated and uploaded but never accepted — releasing the allocation and deleting the bytes. UnallocateArguments carries an optional Cause (the /space/blob/add task link) so the upload service can recover which storage node holds a parked blob, which has no registration or acceptance to look up by; storage nodes ignore it. Idempotent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
We had a conversation about this unallocating a blob:
|
pyropy
left a comment
pyropy
left a comment
There was a problem hiding this comment.
Implementation looks good to me, but I'm going to wait for us to agree on the command name before giving it my approval.
Per PR #46 review (alanshaw): 'allocate' allocates space on a node, not in a space, and a blob may be held by multiple spaces — 'unallocate' is the wrong verb for a per-space cancellation. The single capability becomes two, one per hop: - /blob/abort — the client-facing verb, served by the upload service (subject = space). AbortArguments{Space, Digest, Cause}; Cause (the /space/blob/add task link) is now REQUIRED — it is how the service recovers which storage node holds a parked blob, which has no registration or acceptance to look up by. - /blob/reject — the 'don't accept' inverse of /blob/accept, served by storage nodes (subject = provider), typically translating an abort. RejectArguments{Space, Digest}. Drops the space's allocation; bytes are deleted once no space holds one; accepted blobs are refused (use /blob/remove). A blob's lifecycle on a node ends in exactly one of /blob/accept or /blob/reject. cbor/dagjson marshalers regenerated; round-trip tests for both argument types.
|
Yea okay good call, agreed. I went with your
So a parked blob (allocated + PUT, sitting on the node outside the PDP pipeline) now has exactly two exits, and they're mutually exclusive.
@pyropy this should unblock your review (and provide some context) |
3 participants
blob/removemodified to include the space a blob is being removed fromblob/unallocatecapability implemented permitting an allocated but unaccepted blob to be removed.