jesse/ycloud-cloudflare
1
0
Fork 0
Code Issues 5 Pull requests Projects Releases Packages Wiki Activity Actions

Receive lifecycle: serialize terminal state with an epoch #4

New issue
Open
opened 2026-05-06 04:58:53 +02:00 by jesse · 0 comments
jesse commented 2026-05-06 04:58:53 +02:00
Owner
Copy link

Background

Receive pause, resume, revoke, delete, upload, and finalize paths are currently coordinated through KV state, tombstones, and targeted cleanup. This follow-up tracks a durable per-link lifecycle epoch so late anonymous operations cannot race terminal owner/admin actions across isolates.

Source: Deferred from receive links fix pass after PR multi-agent code review
File: worker.js:3938, worker.js:4029
Branch: feature/receive-links-foundation

Failure mode

  • Owner/admin terminal operations mutate receive metadata and cleanup active upload state.
  • Anonymous upload, part, complete, and finalize paths can run concurrently on separate Worker isolates.
  • KV tombstones and cleanup reduce the race window, but there is no single durable epoch checked by all mutation paths before and after R2 commits.

Why deferred from receive links fix pass

  • A lifecycle epoch requires a design decision about the authoritative per-link state owner, likely a Durable Object or equivalent serialized state machine.
  • Applying that design during the fix pass would have changed several public and internal receive contracts at once.

Proposed work

  • Define the authoritative receive lifecycle state model and epoch fields.
  • Serialize pause, resume, revoke, delete, init, upload, part, complete, abort, and finalize against that state.
  • Include the accepted epoch in upload/finalization ledgers and reject stale operations deterministically.
  • Preserve finalization-pending recovery for uploads committed before a terminal epoch change when policy allows it.
  • Document terminal-state behavior for late upload, complete, abort, and finalize requests.

Acceptance

  • Tests simulate revoke/delete racing with upload init, part, complete, and finalize.
  • Stale operations with an old epoch return deterministic 410, 423, or documented retryable responses.
  • Finalization-pending records are either recoverable or explicitly rejected according to the documented policy.
  • Existing pause/resume owner behavior remains backward-compatible for non-terminal operations.

References

  • Follow-up from feature/receive-links-foundation receive-links review fix pass.
## Background Receive pause, resume, revoke, delete, upload, and finalize paths are currently coordinated through KV state, tombstones, and targeted cleanup. This follow-up tracks a durable per-link lifecycle epoch so late anonymous operations cannot race terminal owner/admin actions across isolates. **Source:** Deferred from receive links fix pass after PR multi-agent code review **File:** `worker.js:3938`, `worker.js:4029` **Branch:** `feature/receive-links-foundation` ## Failure mode - Owner/admin terminal operations mutate receive metadata and cleanup active upload state. - Anonymous upload, part, complete, and finalize paths can run concurrently on separate Worker isolates. - KV tombstones and cleanup reduce the race window, but there is no single durable epoch checked by all mutation paths before and after R2 commits. ## Why deferred from receive links fix pass - A lifecycle epoch requires a design decision about the authoritative per-link state owner, likely a Durable Object or equivalent serialized state machine. - Applying that design during the fix pass would have changed several public and internal receive contracts at once. ## Proposed work - [ ] Define the authoritative receive lifecycle state model and epoch fields. - [ ] Serialize pause, resume, revoke, delete, init, upload, part, complete, abort, and finalize against that state. - [ ] Include the accepted epoch in upload/finalization ledgers and reject stale operations deterministically. - [ ] Preserve finalization-pending recovery for uploads committed before a terminal epoch change when policy allows it. - [ ] Document terminal-state behavior for late upload, complete, abort, and finalize requests. ## Acceptance - Tests simulate revoke/delete racing with upload init, part, complete, and finalize. - Stale operations with an old epoch return deterministic `410`, `423`, or documented retryable responses. - Finalization-pending records are either recoverable or explicitly rejected according to the documented policy. - Existing pause/resume owner behavior remains backward-compatible for non-terminal operations. ## References - Follow-up from `feature/receive-links-foundation` receive-links review fix pass.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix/share-password-auth
feature/folder-sharing
feature/receive-links-foundation
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jesse/ycloud-cloudflare#4
No description provided.