Skip to content

id: generic event-body persistence, retrieval and range-sync — prerequisite for the didit tracker phases (#2031) #4837

Open

Description

@dezren39

Filed by queue triage task 6875 (2026-11-03) from the design record on main, doc/2026-11-01_design_id2031.md §2, which names this as "a prerequisite missing from #3788–#3790's current dependency graph" — it has no issue of its own, so the gap is invisible to the fleet.

The gap (per the design record, verified against main 2026-11-03)

  • ChainExt carries a free-string kind and optional group (pkgs/id/src/chain.rs, root id package), and the signed header commits to a body's hash and size while the body itself is separate.
  • Ingest accepts and verifies a supplied body (pkgs/id/src/event_store/ingest.rs), but store_event writes event.bytes (the signed header) only (pkgs/id/src/event_store/mod.rs); range sync sends stored events and fork-proof headers (pkgs/id/src/event_store/sync.rs).
  • Consequence: a didit.* CBOR body can be validated at ingest but is not yet available for later retrieval or cross-device replication.

Scope

Design + implement generic application event-body persistence, retrieval, and range-sync in pkgs/id (not didit-specific), so any kind with a CBOR body — starting with the four didit.* kinds from issue #3788 — round-trips: stored at ingest, retrievable by event id/hash, and carried by range sync with the same integrity checks as headers.

Acceptance

  • A stored event with a generic body can be retrieved byte-identically after restart.
  • Range sync between two nodes transfers bodies for events the peer lacks, with hash/size verification against the signed header.
  • Existing header-only kinds are unaffected; tests cover body-present and body-absent events.

Relations

Acceptance criteria

  • Generic event-body persistence exists for pkgs/id: bodies can be stored, retrieved by event id, and range-synced without per-type bespoke code.
  • Retrieval of a missing body returns a typed not-found (not a panic or silent empty).
  • Range-sync is idempotent: re-syncing a range does not duplicate bodies.
  • Covered by tests exercising persistence, retrieval, and a repeated range-sync.

Activity

  1. added
    app/idPackage/app: id (pkgs/ or apps/ in this repo)
    effort/mMedium: expected under 1 day of work
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    priority/normalOrdinary priority (the default)
    on Nov 3, 2026
  2. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    Intake review

    Related: see the issue body and its linked references; no merged PR was found that resolves this issue at intake time (checked at fleet-monitor run 2026-11-03 04:12 CST).

    Notes: Design-bearing slice (generic event-body persistence for pkgs/id). Suggested approach: mirror the existing per-type body store's shape before inventing a new one, and confirm the range-sync contract with the slices that consume it. Risks: sync idempotency and body-size bounds — both are called out in the criteria.

    Risks / suggested approach: as noted above; acceptance criteria have been appended to the issue body and labels normalized by the fleet monitor.

    🤖 Agent note · filed

    • Agent: fleet monitor (repo-fleet-monitor)
    • Session / ID: repo-fleet-monitor run 2026-11-03 04:12 CST
    • Found via: monitor reconciliation (intake enrichment, protocol §5)
    • Task: Intake enrichment — acceptance criteria, labels, related context.
  3. added
    queue/queuedHas a queued task in the Supabase agent queue
    source/creatorFiled by the new-issue-creator job
    task/triageQueue packet kind: verify, reproduce, and route this item
    on Nov 3, 2026
  4. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    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

  5. added
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 3, 2026
  6. 27 remaining items

  7. dezren39 commented on Nov 4, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

  8. dezren39 commented on Nov 4, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

  9. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

  10. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    Picked up as task 9198 by lane code-c (repo-queue worker) and handed off to the opencode execution lane per the execution-lane assignment for task 9198. The laptop claimant launches the bound opencode session for task 9198; this lane does not work issue #4837 directly. Note: task 9198 is at attempts 15/24.

  11. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

  12. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

  13. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

  14. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

  15. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

  16. added
    queue/queuedHas a queued task in the Supabase agent queue
    and removed
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 5, 2026
  17. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

    • Agent: fleet monitor
    • Session / ID: task 9198 (repo-fleet-monitor run 2026-11-05T15:32:18Z)
    • Found via: monitor reconciliation (Duty 1 claim/label divergence repair)
    • Task: Claim evaporated: task 9198 is queued and unclaimed in repo-health-code-pilot, but this issue still carried claimed labels. Labels reset to the truth (queue/queued + status/needs-triage). Checkpoint stage at evaporation: handed_off.
    • Expectation: The next lane claim picks task 9198 up from the queued state and posts a fresh pickup note.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

app/idPackage/app: id (pkgs/ or apps/ in this repo)effort/mMedium: expected under 1 day of workexpediteImportant - do this very soon, before anything not expeditedmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/normalOrdinary priority (the default)queue/queuedHas a queued task in the Supabase agent queuesource/creatorFiled by the new-issue-creator jobstatus/needs-triageNot yet triaged; needs a first looktask/triageQueue packet kind: verify, reproduce, and route this item

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions