Module pull 

Pull-event processing — pure logic shared by wire pull and the daemon sync loop.

P0.1 (0.5.11): refuse to silently advance cursor past events the running binary cannot process. The cursor only advances to the last event in the contiguous prefix that was either successfully written or rejected for a TERMINAL reason. Events rejected for TRANSIENT reasons (unknown kind, signer not yet pinned) block the cursor — so the next pull re-sees them and a future binary version or freshly-pinned peer can pick up where we left off.

Without this rule, an old daemon running against a newer relay silently ate v0.5.x pair_drop events (kind=1100) it could neither pin nor verify, advancing the cursor past them. Today’s debug session lost ~30 min to it.

Adversarial test: tests/pull_unknown_kind.rs synthesises a kind=9999 event, runs process_events, and asserts the cursor stays put + the rejection carries binary_version= and unknown_kind= so the failure is loud on every retry.

Cursor advancement rules:

• terminal reject (bad signature, missing field, event_id mismatch, revoked key) → advance past, retry won’t help.
• transient reject (unknown kind to THIS binary, signer not in trust) → DO NOT advance past, future state may unblock.
• success → advance past.

The first transient reject “blocks” the cursor; subsequent events in the batch are still processed for their inbox-write side effect but cannot advance the cursor beyond the block point. Re-pull observes the same blocking event again → visible failure mode.

Structs

PullResult

Outcome of processing a batch of pulled events.

Functions

is_known_kind

Is kind known to THIS binary? Used by P0.1 to refuse silent cursor advance past events from a future protocol version.

process_events

Process a pulled-event batch. Mutates inbox files + relay state (via pair_invite side effects) but returns the new cursor target rather than writing it — caller persists.