Skip to content

id(boards): BoardFork records are in no board's replication set — fork provenance never replicates and replicas still report Complete #4081

Open

Description

@dezren39

Summary

A signed BoardFork record (BoardObject::BoardFork, pkgs/id/src/boards.rs:232-238) belongs to no board's replication set, so fork provenance can never replicate: export_board / replicate_board_from never transfer it, and replica_status_against still reports the replica Complete — the exact silent-lag failure the federation design (#3806) says must never happen.

Evidence (verified this run, main @ 74a872a)

  • BoardObject::board_ref() returns None for BoardFork (boards.rs:389, grouped with Board and Theme).
  • board_object_set() (boards.rs:899-935) seeds the set with objects whose hash is the board root or whose board_ref() == Some(board), then expands only Board::{forked_from, theme_ref} and Theme::forked_from dependencies. A BoardFork matches neither seed rule for its source board nor for its fork board, and no closure step adds it.
  • Laptop probe (verbatim boards.rs @ 74a872a, md5 e142727a25d638136a27ac9ecfb7c3f9, in ~/git/fleet/probe-2026-11-01-laneB-boardsfork/ on the laptop): source board + one frontier thread + forked board + a valid signed BoardFork record citing the thread as its frontier (graph len = 4). Results:
    • board_object_set(source) contains fork record: false
    • board_object_set(fork) contains fork record: false
    • export_board(source) len = 2, export_board(fork) len = 2 (of 4 graph objects)
    • replicate_board_from(fork) into a fresh graph: state Complete, transferred = 2, replica has no fork record; replica_status_against reports expected=2 / present=2 / missing=0.
  • No test in boards.rs constructs a BoardFork object at all (the replication tests cover themes, ancestor roots, and listings only), so the gap is untested as well as unfixed.

Secondary, same fix area: the fork's cited source_frontier objects are scoped to the source board, so even the fork board's set omits the frontier content the fork record says it starts from.

Why it matters

The BoardFork record is the only signed statement of a fork's provenance and cited starting frontier. A replica that reports Complete without it presents an incomplete fork history as fully converged — silently, which the module docs explicitly promise not to do ("a lagging replica is never silently presented as current", boards.rs:1012-1023 area / module header).

Acceptance criteria

  • A BoardFork record is included in a well-defined board replication set (its fork board's, its source board's, or both — the choice is stated in the module docs), and board_object_set's dependency closure pulls in everything validate_links needs to accept it on a fresh graph (both roots, and the cited frontier objects if the record travels with the fork board).
  • replicate_board_from transfers the fork record; a replica of a forked board holds it afterwards.
  • replica_status_against can no longer report Complete for a graph missing an in-set fork record.
  • New tests construct a real BoardFork (none exist today), assert it is in the chosen set(s), and assert end-to-end replication of a forked board including its fork record and cited frontier.
  • Existing boards tests still pass.

Activity

  1. added
    kind/bugSomething isn't working (prefixed form of the classic bug label)
    task/triageQueue packet kind: verify, reproduce, and route this item
    source/creatorFiled by the new-issue-creator job
    priority/normalOrdinary priority (the default)
    queue/queuedHas a queued task in the Supabase agent queue
    app/idPackage/app: id (pkgs/ or apps/ in this repo)
    effort/sSmall: expected under 2 hours of work
    on Nov 1, 2026
  2. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · filed

    • Agent: new-issue-creator-code-b
    • Session / ID: new-issue-creator-code-b cron run 2026-11-01 17:50 CST
    • Found via: filed this run
    • Task: Filed this issue: BoardObject::board_ref() returns None for BoardFork (pkgs/id/src/boards.rs:389), so a signed fork record matches neither seed rule of board_object_set (boards.rs:899-935) for its source or fork board and no dependency-closure step adds it — fork provenance never replicates, yet replica_status_against reports the replica Complete. Verified on the laptop with the verbatim boards.rs @ 74a872a (md5 e142727a25d638136a27ac9ecfb7c3f9; probe ~/git/fleet/probe-2026-11-01-laneB-boardsfork/): 4-object graph, both exports len 2, fork record in neither set, replica Complete with no fork record. No existing test constructs a BoardFork object.
    • Expectation: effort s; done when the fork record is in a stated board replication set with the closure its acceptance needs, replication transfers it, status cannot report Complete without it, and new tests build a real BoardFork end-to-end.
    • Links: id(boards): replicate signed board object sets across hosts and publish listings #3806 id(boards): replicate signed board object sets across hosts and publish listings #3806
  3. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · adopted as Phase 3 of design #4113 — open ruling decided

  4. 44 remaining items

  5. added
    queue/blockedQueue or user escalation state
    status/blockedQueue or user escalation state
    user/escalatedQueue or user escalation state
    and removed
    work/assignedQueue worker lifecycle state
    on Nov 2, 2026
  6. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    agent-note:v1
    event: picked_up
    task: 6286 (repo-health-code-pilot, repo-worker-code; OpenChamber scheduled lane ec118cad-0fd3-4652-91c4-27432f2f2efd)
    state: claimed via atomic queue claim; first checkpoint records origin=openchamber-scheduled-lane.
    fresh_evidence: #4081 OPEN; bound PR #4545 OPEN, branch queue/6286-4081-boardfork-replication, authored by dezren39 (Drew); basic OpenCode metered-provider guard PASS, CodeRabbit skipping. No PR diff/files inspected, worktree untouched.
    next: escalate — merge decision is Drew-only on a Drew-owned PR.

    agent-note:v1
    event: blocked (escalated-to-user)
    task: 6286 (repo-health-code-pilot, repo-worker-code; OpenChamber scheduled lane ec118cad-0fd3-4652-91c4-27432f2f2efd)
    state: blocked; claim released. PR #4545 is Drew-authored so the worker must never touch or merge it (runbook non-negotiable). Work itself is ready: CI green on the PR head.
    fresh_evidence: gh pr checks 4545 — basic guard PASS 15s; PR still OPEN, still Drew-authored.
    resume: Drew merges #4545 (fixes #4081); a later lane then completes 6286 as fixed_merged with fresh verification.
    labels: queue/blocked, status/blocked, user/escalated; removed queue/parked, status/parked, work/assigned.

  7. added
    queue/queuedHas a queued task in the Supabase agent queue
    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
  8. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

  9. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · correction + blocked (escalated-to-user)

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/sSmall: expected under 2 hours of workkind/bugSomething isn't working (prefixed form of the classic bug label)priority/normalOrdinary priority (the default)queue/blockedQueue or user escalation statesource/creatorFiled by the new-issue-creator jobsource/design-architectFiled by the repo design architect jobstatus/blockedQueue or user escalation statetask/triageQueue packet kind: verify, reproduce, and route this itemuser/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