Skip to content

Worker sync protocol uses bulk SyncBatch instead of per-author Advertise/Request/Response #65

@intendednull

Description

@intendednull

Problem

The worker sync actor (crates/worker/src/actors/sync.rs:68-82) uses WorkerRequest::Sync { server_id, heads } with bulk WorkerResponse::SyncBatch { events } responses. This does not match the spec's per-author sync protocol.

Spec requires:

pub enum SyncMessage {
    /// "Here's what I have." Sent on connect and periodically.
    Advertise(HeadsSummary),
    /// "I need events from these authors after these seq numbers."
    Request(Vec<AuthorRequest>),
    /// "Here are events you're missing."
    Response(Vec<Event>),
}

pub struct AuthorRequest {
    pub author: EndpointId,
    pub after_seq: u64,
}

Current implementation:

  • Sync broadcasts a single WorkerRequest::Sync with heads
  • Response is a bulk SyncBatch of all events, not per-author
  • No Advertise message for proactive head exchange
  • No AuthorRequest for targeted per-author fetching

Impact

  • Redundant data transfer — bulk batches include events the requester already has
  • No per-author granularity — cannot request specific authors' missing events
  • Doesn't support parallel fetching from different authors
  • Mismatched with the client's sync protocol evolution (Migrate client SyncRequest to heads-based sync protocol #43)

Suggested fix

Implement the spec's three-phase sync:

  1. Advertise: periodically broadcast HeadsSummary (already partially done via heads_summaries())
  2. Request: compare received heads against local DAG, request missing per-author ranges
  3. Response: send requested events in seq order per author

Location

  • crates/worker/src/actors/sync.rs:68-82
  • crates/worker/src/actors/state.rs:34-43 (response format)
  • crates/common/src/worker_types.rs (WorkerRequest/WorkerResponse types)

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingnetwork

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions