Skip to content

ConnectionSettings: builder/Default to stop field-additions churning ~55 struct-literal sites #323

@fasterthanlime

Description

@fasterthanlime

Problem

ConnectionSettings (vox-types/src/message.rs) is a plain #[derive(Facet)] struct constructed via struct literals (ConnectionSettings { parity, max_concurrent_requests, initial_channel_credit }) in ~55 sites across vox-core (session, handshake, builders, golden-vector tool) and the test suites.

It has no Default and no builder, so adding any field is a breaking, high-churn change: every literal must be edited, and the diff drowns the actual feature in mechanical noise. This already bit initial_channel_credit (added with #[facet(default = …)] so the wire stays back-compatible, but every Rust constructor still had to be touched).

Concretely: while adding vox::Fd / SCM_RIGHTS fd-passing, the natural place to advertise the peer-software capability is ConnectionSettings.fd_passing: bool (schema-evolvable via #[facet(default = false)]). That single field is correct and idiomatic at the schema layer — but it would require mechanically touching ~55 unrelated struct literals, so it had to be deferred even though the design called for it.

Proposal

Give ConnectionSettings a builder / Default-based construction so capability/limit fields can be added without a codebase-wide sweep:

  • ConnectionSettings::new(parity) returning sensible defaults, plus .max_concurrent_requests(n) / .initial_channel_credit(n) / future .fd_passing(true) chained setters; or
  • a #[non_exhaustive] + ConnectionSettings { ..ConnectionSettings::default_for(parity) } pattern (parity has no meaningful default, so a default_for(parity) constructor is probably the cleanest seam).

Either way the goal: adding a future capability field is a one-line change to the struct + the builder, not a ~55-site mechanical edit.

Notes

  • Keep #[facet(default = …)] on new fields so the wire format stays back-compatible with older peers (older peers omit the field → default).
  • Migrating the existing ~55 sites is itself a mechanical-but-large change; doing it once via the builder pays for itself the next time a field is added (fd-passing being the immediate motivating case).

Filed while implementing vox::Fd fd-passing (downstream: stax privileged Linux profiler daemon).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions