Location
src/relay.rs — the SubscriberOptions struct.
Problem
The RELAY spec defines a canonical subscriber-configuration type (named consistently across every protocol adapter) that carries channel depth, back-pressure policy, and two optional protocol-routing fields — one used only by SOME/IP-style adapters and one used only by DDS-style adapters, with every other protocol required to ignore them. The point of keeping the field set and name identical across protocols is that the type is swappable between them.
rust-LIN's equivalent type, SubscriberOptions, already diverges from the spec's name (SubscriberOptions vs the spec's SubscriberConfig), and it's also missing the two protocol-routing fields entirely. In their place it adds a bespoke rate_limit_per_sec: u32 field that has no counterpart in the spec at all. That field is enforced silently inside the subscriber's push path, dropping frames with no visible counter tied to it — an undocumented deviation from both the subscriber model and the drop-count metric semantics that are supposed to account for all dropped frames.
Suggested fix
Rename SubscriberOptions to SubscriberConfig and add the two routing fields (LIN can ignore them, per the spec's own rule that non-applicable protocols must disregard them) so the type is structurally consistent with the rest of the ecosystem. Either remove rate_limit_per_sec or turn it into a clearly documented, LIN-specific extension whose drops are counted into the standard drop-count metric.
Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.
Location
src/relay.rs— theSubscriberOptionsstruct.Problem
The RELAY spec defines a canonical subscriber-configuration type (named consistently across every protocol adapter) that carries channel depth, back-pressure policy, and two optional protocol-routing fields — one used only by SOME/IP-style adapters and one used only by DDS-style adapters, with every other protocol required to ignore them. The point of keeping the field set and name identical across protocols is that the type is swappable between them.
rust-LIN's equivalent type,
SubscriberOptions, already diverges from the spec's name (SubscriberOptionsvs the spec'sSubscriberConfig), and it's also missing the two protocol-routing fields entirely. In their place it adds a bespokerate_limit_per_sec: u32field that has no counterpart in the spec at all. That field is enforced silently inside the subscriber's push path, dropping frames with no visible counter tied to it — an undocumented deviation from both the subscriber model and the drop-count metric semantics that are supposed to account for all dropped frames.Suggested fix
Rename
SubscriberOptionstoSubscriberConfigand add the two routing fields (LIN can ignore them, per the spec's own rule that non-applicable protocols must disregard them) so the type is structurally consistent with the rest of the ecosystem. Either removerate_limit_per_secor turn it into a clearly documented, LIN-specific extension whose drops are counted into the standard drop-count metric.Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.