id: partial-holder re-serving while downloading, under LIST 8 serving budgets

Parent: #2050 (investigation: BitTorrent-style chunk retrieval for graph objects), epic #2056. Follow-up C of the #2050 investigation. Depends on follow-up A (holder discovery + wired blob gate).

Problem

In the #2050 design every downloader becomes a useful partial holder the moment its first chunk group verifies — FsStore persists verified ranges, and bao verification makes a partial holder's ranges exactly as trustworthy as a complete holder's. Nothing in pkgs/id enables, announces, or budgets that re-serving today, and turning it on widens the serving surface: swarm range-serving must be covered by the LIST 8 abuse controls (per-IP / per-ID / per-world MB and message budgets, rate limits) before any public server serves swarm traffic.

Scope

A node serving a world re-serves the verified ranges it holds for that world's blobs, subject to the blob gate (members of a referencing world only).
Announce partial holdings through follow-up A's provider table/announcements (held-ranges summary, not just complete/partial boolean).
Wire serving budgets: per-world and per-peer caps on swarm range-serving (bytes/window), reusing the LIST 8 budget shapes; a node over budget declines new range requests cleanly (requester requeues elsewhere — the id: investigate: BitTorrent-style chunk retrieval for graph objects #2050 flow already tolerates this).
Eviction policy: LRU under store pressure for fetched blobs; a node configured as a world's public server must not silently evict that world's only-known copy — surface it in config/status instead.

Acceptance criteria

A third node can complete a blob fetch where the middle node only ever held (and served) a partial range set it had itself just downloaded.
Budget caps demonstrably stop range-serving when exceeded, and requesters recover by scheduling other holders.
Tests cover gate behaviour for partial serving (non-member refused, indistinguishable refusal).

Not in scope: global discovery (follow-up D); permanent-feature status for the PoC scheduler (follow-up B's review round decides).

CODE-1125

Intake review — fleet monitor, 2026-10-29

Related: parent id: investigate: BitTorrent-style chunk retrieval for graph objects #2050, epic epic: ID platform expansion — apps, comms, currency, hosting, boards (2026-10-28 directive, LIST 6–15) #2056; follow-up C. Depends on follow-up A (holder discovery + wired blob gate); sibling id: investigate global (Mainline DHT) content discovery for public worlds #2263 (follow-up D).
Still live: filed today; the dependency (follow-up A) has not landed, so the work cannot have been done yet.
Notes: body already carries acceptance criteria; none appended. The LIST 8 serving-budget constraint is the core design limit — any approach that overserves partial holders breaks the budget model.
Risks: re-serving while downloading interacts with the blob gate; test the budget accounting explicitly, not just the happy path.
Suggested approach: after A lands: partial-holder serve path with budget accounting tests first, then the retrieval integration.
Labels normalized: kind/enhancement, source/human, priority/normal, effort/m, status/needs-triage, meta/enriched.

🤖 Agent note · picked-up

Agent: queue worker (repo-worker-code), lane code-l
Session / ID: task 7862
Task: Triage issue id: partial-holder re-serving while downloading, under LIST 8 serving budgets #2262 (partial-holder re-serving under LIST 8 budgets) at current main: confirm still-live, scope the fix or close with evidence, record blockers/ordering.
Next: revalidate dependency issue id: holder discovery for blob hashes — provider table, gossip announcements, wire the blob gate #2260 and current pkgs/id state.

🤖 Agent note · triaged — blocked on dependency issue #2260

Agent: queue worker (repo-worker-code), lane code-l
Session / ID: task 7862
Verdict: issue id: partial-holder re-serving while downloading, under LIST 8 serving budgets #2262 is STILL LIVE at current main and correctly scoped, but it cannot proceed yet. It is follow-up C of the closed investigation issue id: investigate: BitTorrent-style chunk retrieval for graph objects #2050 and explicitly depends on follow-up A — issue id: holder discovery for blob hashes — provider table, gossip announcements, wire the blob gate #2260 (holder discovery + wired blob gate).
Dependency state (verified fresh 2026-11-03): issue id: holder discovery for blob hashes — provider table, gossip announcements, wire the blob gate #2260 is OPEN, labelled status/blocked + queue/blocked + user/escalated. Its task 5806 escalated on 2026-11-01: LocalEvents::publish writes group=None, EventStore::documents() exposes no world binding, and id serve has no authoritative membership source — so the blob gate that partial-holder re-serving must reuse does not exist yet, and the canonical document↔world decision is Drew's (already escalated on issue id: holder discovery for blob hashes — provider table, gossip announcements, wire the blob gate #2260; not re-escalated here).
Evidence nothing of issue id: partial-holder re-serving while downloading, under LIST 8 serving budgets #2262 has landed: no PR references issue id: partial-holder re-serving while downloading, under LIST 8 serving budgets #2262 except the merged investigation PR docs: BitTorrent-style chunk retrieval investigation (#2050) #2811 (docs for issue id: investigate: BitTorrent-style chunk retrieval for graph objects #2050); code search shows FsStore only in its existing store paths (pkgs/id/src/store.rs) with no partial-range announcement or swarm range-serving budget code.
Ordering: (1) Drew rules on issue id: holder discovery for blob hashes — provider table, gossip announcements, wire the blob gate #2260's escalated questions → (2) issue id: holder discovery for blob hashes — provider table, gossip announcements, wire the blob gate #2260 implementation lands (provider table, held-ranges announcements, wired blob gate) → (3) only then issue id: partial-holder re-serving while downloading, under LIST 8 serving budgets #2262: partial-holder serve path reusing that gate, LIST 8 per-world/per-peer serving budgets with over-budget clean decline, LRU eviction with public-server no-silent-evict surfacing, and the three-node partial-fetch + budget + gate tests in its acceptance criteria.
Fix path once unblocked: budget-accounting tests first, then the retrieval integration (per the 2026-10-29 intake note).
Labels: status/blocked set; blocker is the dependency above, recorded here per the triage acceptance criteria.

agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03

🤖 Agent note · done

Agent: queue worker (repo-worker-code), lane code-e
Session / ID: task 8603
Found via: queue claim
Task: Triage of issue id: partial-holder re-serving while downloading, under LIST 8 serving budgets #2262 — verdict: STILL LIVE, blocked on dependency issue id: holder discovery for blob hashes — provider table, gossip announcements, wire the blob gate #2260; the full triage already landed today as task 7862 (lane code-l, note 2026-11-03T15:23Z). This pass re-verified the dependency state fresh rather than re-triaging.
Expectation: triage done = verdict with fresh evidence + routing confirmed.
Links: task 8603 (queue); task 7862 (queue); issue id: holder discovery for blob hashes — provider table, gossip announcements, wire the blob gate #2260

Fresh check (2026-11-03T21:05Z): issue #2260 (follow-up A: holder discovery + wired blob gate) is still OPEN with status/blocked + user/escalated — the document↔world membership decision it waits on is still Drew's, already escalated on issue #2260 itself (not re-escalated here). No PR implements issue #2262 (the only search hit, PR #2811, is the merged parent investigation #2050's docs). Nothing about the task 7862 verdict has changed, so no new fix task is enqueued: implementation of issue #2262 starts when issue #2260 lands. Labels set to queue/blocked + status/blocked to match the standing verdict.

Navigation Menu

Repository navigation

id: partial-holder re-serving while downloading, under LIST 8 serving budgets #2262

Problem

Scope

Acceptance criteria

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id: partial-holder re-serving while downloading, under LIST 8 serving budgets #2262

Description

Problem

Scope

Acceptance criteria

Activity

developing-today commented on Oct 29, 2026

dezren39 commented on Oct 29, 2026

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

developing-today commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions