Skip to content

feat(blob): add AllocationExpired and AllocationNotFound accept errors - #91

Merged
alanshaw merged 1 commit into
mainfrom
ash/feat/accept-allocation-errors
Nov 11, 2026
Merged

alanshaw merged 1 commit into
mainfrom
ash/feat/accept-allocation-errors

Conversation

@alanshaw

Copy link
Copy Markdown
Member

Adds two named failures for /blob/accept, so a caller can tell why a storage node refused an accept without matching on message text:

  • AllocationExpired: the allocation passed its expiry before the content was delivered.
  • AllocationNotFound: the node holds no allocation for the blob. It was never made, was rejected, or was removed after it expired.

Piri returns both today as a generic HandlerExecutionError. A Piri PR that returns these names follows.

🤖 Generated with Claude Code

A storage node reports them from /blob/accept: AllocationExpired when the
allocation passed its expiry before the content was delivered, and
AllocationNotFound when it holds no allocation for the blob.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

No active review issues are identified, and the change clearly defines and documents stable named errors for distinguishing allocation failure conditions.

No open issues 🎉

What changed in this PR

Adds stable, named errors for /blob/accept failures so callers can distinguish expired allocations from missing allocations without matching error messages.

Changes:

  • Defines AllocationExpiredErrorName and ErrAllocationExpired.
  • Defines AllocationNotFoundErrorName and ErrAllocationNotFound.
  • Documents the conditions represented by each failure.
File Description
commands/​blob/​accept.go Adds two exported, named allocation-related accept errors and documents the conditions they represent.

Review effort: Lite

@alanshaw
alanshaw merged commit ff40732 into main Nov 11, 2026
9 checks passed
alanshaw added a commit to fil-forge/piri that referenced this pull request Nov 11, 2026
…tion (#229)

A `/blob/accept` for an allocation that had expired, been rejected, or
been removed after expiry failed with a generic `HandlerExecutionError`.
The upload service could only tell these cases apart by reading the
message. They now fail with a named error:

- `AllocationExpired`: the allocation passed its expiry before the blob
was received.
- `AllocationNotFound`: the node holds no such allocation. It was never
made, was rejected, or was removed by the expiry task.

What stays the same:

- An allocation past its expiry whose blob was received in time is still
accepted, as the spec asks.
- An accept that arrives before the blob, on an allocation that has not
expired, still fails with a short-lived error and can be sent again.

Both new failures are ordinary receipts, where the old one was
short-lived. Sending the same accept again returns the same answer; the
blob has to be allocated again.

The error names come from fil-forge/libforge#91. Picking that up also
brings Piri up from its October libforge version.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5.2 <noreply@anthropic.com>
alanshaw added a commit to fil-forge/ucan-protocol-specs that referenced this pull request Nov 12, 2026
…tion (#10)

Documents the two named failures a storage node returns from
`/blob/accept`:

- `AllocationExpired`: the allocation passed its expiry before the
content was delivered.
- `AllocationNotFound`: the node holds no allocation for the blob. It
was never made, was rejected, or was removed after it expired.

It also states that an allocation past its expiry whose content was
delivered is still accepted.

The rule that an accept blocks until content is delivered is replaced
with what the storage node does: an accept that arrives before the
content fails, and can be invoked again once the content is there.

Piri returns these as of fil-forge/piri#229; the names are defined in
fil-forge/libforge#91.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5.2 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants