Skip to content

Phase 3: blob gate is not wired into serve, so blobs are still served to any peer #173

Open

Description

@dezren39

The blob gate (P3.4) is implemented behind a WorldAccess interface, but serve.rs, local.rs and commands/world.rs still serve get and observe to any peer. Wiring needs a real referencing-world index (including HashSeq children) and a membership query. Until then, the product behaves as before. High priority for the next Phase 3 step.

Activity

  1. dezren39 commented on Oct 24, 2026

    @dezren39
    MemberAuthor

    id train triage (2026-10-24): too-big-needs-design — blob-gate wiring into serve needs a referencing-world index (incl. HashSeq children) and a membership query.

  2. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  3. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · done (triage verdict: CONFIRMED)

    • Agent: queue worker (repo-worker-code), Lane A shift
    • Session / ID: queue task 2019 (triage)
    • Found via: queue claim · repo-health-code-pilot
    • Task: Triage complete — CONFIRMED at current main (HEAD 2953f27), routed to a scoped fix packet (queue task 2953).
    • Evidence:
      • pkgs/id/src/blob_gate.rs:16-18 (module header, at HEAD): "The reference index and the membership query are behind WorldAccess. FoldedWorlds answers membership from the folded worlds. Its reference index has no producer yet, so blob_events is not wired into id serve."
      • blob_gate::blob_events (blob_gate.rs:166) has zero callers anywhere in pkgs/id/src outside its own module/tests (grep-verified this run).
      • What serve actually wires: commands/serve.rs:827-832 passes crate::access::blobs_events to BlobsProtocol; access.rs:139-145 shows that handler's event mask intercepts push only, and its own doc comment states: "Reads (get/observe) are unaffected." local.rs wires the same handler. So any connected peer can get/observe any blob by hash — the issue's claim, verbatim in the code's own words.
      • The event-pull PullGate (pull_policy.rs) is a different surface (event sync, cf. id phase-8/platform-completion: freshness-window and pull-policy config are not wired into server/world settings or CLI defaults #798); pull_policy.rs:16 itself notes the blob gate "still requires membership to fetch" — the design intent this wiring realizes.
    • Expectation: fix task 2953 (small_fix, dedupe repo-health:v1:fix:developing-today/code:issue:173) — done = referencing-world index producer (incl. HashSeq children) + blob_events wired into id serve (push gating preserved), member/non-member get+observe tests, CI green.
    • Links: follow-up task 2953 · gate https://github.com/developing-today/code/blob/main/pkgs/id/src/blob_gate.rs
  4. added
    queue/queuedHas a queued task in the Supabase agent queue
    and removed
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Oct 29, 2026
  5. dezren39 commented on Oct 29, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · correction

    • Agent: queue worker (repo-worker-code), Lane A shift
    • Session / ID: queue task 2019 (triage)
    • Correction to the triage verdict above: the follow-up fix task ID is 2956 (not 2953 — that number was my error; 2956 is the task the enqueue verb returned, dedupe repo-health:v1:fix:developing-today/code:issue:173). Everything else in the verdict stands.
  6. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 1, 2026
  7. 116 remaining items

  8. added and removed
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 3, 2026
  9. developing-today commented on Nov 3, 2026

    @developing-today
    Contributor

    agent-note:v1
    state: reviewed (coverage loop-back)
    Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 5874 (pr_shepherd, queued, priority 40) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
    Found via: coverage loop-back 2026-11-03

  10. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

    • Agent: fleet monitor
    • Session / ID: queue task 5874 · repo-fleet-monitor run 2026-11-03 10:12 CST (note posted on a delayed retry — the original posting attempts were rejected by a GitHub secondary rate limit; this text is the corrected, re-verified record)
    • Found via: monitor reconciliation
    • Task: Claim/label divergence repair (Duty 1 addendum): at this run's verification, task 5874 was queued and unclaimed (no live lease) while this issue still carried queue/claimed + work/assigned — the claim had evaporated. The monitor reset the labels to the truth (queue/queued + status/needs-triage; since re-verified as landed). Last checkpoint stage on the task: handed_off. The task was also dead-in-queue (attempts at cap); the monitor doubled max_attempts 4 → 8 in the same run. Current task state at this posting: claimed again.
    • Expectation: effort s — the work was not lost, only unheld; the task's subsequent state above is the proof it re-entered the system.
  11. added
    queue/blockedQueue or user escalation state
    status/blockedQueue or user escalation state
    user/escalatedQueue or user escalation state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 3, 2026
  12. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · blocked / escalated

  13. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up for queue task 5177 to revalidate routing and ownership.

  14. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · blocked/escalated: #173 remains open with user/escalated; PR #3917 is open, Drew-authored and Drew-assigned. The queue task is blocked on Drew deciding whether to reassign the work or authorize another owner to address the findings and missing two-peer gated-fetch test. No changes made to the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

queue/blockedQueue or user escalation statesource/creatorFiled by the new-issue-creator jobstatus/blockedQueue or user escalation statetask/pr-shepherdQueue packet kind: shepherd an open PR or PR set to mergeuser/escalatedQueue or user escalation state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions