Skip to content

types/engine: fleet wire versioning is hardcoded v:1 lockstep — add version negotiation to node.register #291

Description

@willwashburn

Severity: medium (architecture) · packages/types/src/fleet-wire.ts:22 (z.literal(1)), relay crates/broker/src/fleet_wire.rs:18-49 (FleetWireVersion::VALUE=1, hard-fail deserializer + test pinning rejection of v:2)

Both sides hard-fail on any version other than 1. There is no min/max version, no capability-version handshake, and no v:2 anywhere. The only negotiated feature flag is relay:delivery-cursor-v1. Inbound broker frames are intentionally non-deny_unknown_fields (additive-field forward-compat within v1), but a version bump is a hard cutover.

What breaks first on skew: if the engine ever emits v:2, the broker rejects every inbound frame — including deliver — so it never acks anything and the mailbox redelivers forever. Conversely a v:2 engine rejects the broker's v:1 node.register. Compat today is purely "deploy in the right order," and the context.update drift shows the system already ships frame-level skew no version check catches.

Recommendation: extend the existing relay:delivery-cursor-v1 capability-handshake pattern — broker advertises a supported version range in node.register, engine replies with the negotiated version + capability set. Converts the lockstep cliff into graceful degradation and makes a future v:2 shippable without a flag day.


Found during a multi-agent cross-repo architecture review of the relay tool/protocol.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions