Skip to content

fix(envoy-protocol): advertise current protocol version#4800

Open
NathanFlurry wants to merge 1 commit intobreak-up/serialize-gateway-actor-keysfrom
engine-stabilize/envoy-protocol-version
Open

fix(envoy-protocol): advertise current protocol version#4800
NathanFlurry wants to merge 1 commit intobreak-up/serialize-gateway-actor-keysfrom
engine-stabilize/envoy-protocol-version

Conversation

@NathanFlurry
Copy link
Copy Markdown
Member

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

Copy link
Copy Markdown
Member Author

NathanFlurry commented Apr 27, 2026

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

@claude
Copy link
Copy Markdown

claude Bot commented Apr 27, 2026

PR #4800 Review: fix(envoy-protocol): advertise current protocol version

Note: This is a DRAFT PR — feedback is provided for early visibility.

Overview

This PR fixes a bug where the deserialize_converters() and serialize_converters() methods on all six versioned envoy-protocol message types (ToEnvoy, ToRivet, ToGateway, ToOutbound, ToEnvoyConn, ActorCommandKeyData) returned only one identity converter (vec![Ok]) when the protocol actually has three schema versions (v1, v2, v3).

The vbare::OwnedVersionedData trait uses converters.len() + 1 to determine the current/latest protocol version. With vec![Ok] (length 1), vbare advertised version 2; with vec![Ok, Ok] (length 2), it correctly advertises version 3, aligning with PROTOCOL_VERSION: u16 = 3 in lib.rs.


Correctness

The fix is correct. The invariant is confirmed by other impls in the codebase:

Type Versions Converter count Version constant
RunnerAllocIdxKeyData V1, V2 1 PEGBOARD_NAMESPACE_RUNNER_ALLOC_IDX_VERSION = 2
NamespaceRunnerConfig V1-V5 4 PEGBOARD_NAMESPACE_RUNNER_CONFIG_VERSION = 5
ToEnvoy (before PR) V1, V2, V3 1 (wrong) PROTOCOL_VERSION = 3
ToEnvoy (after PR) V1, V2, V3 2 (correct) PROTOCOL_VERSION = 3

All six message types are updated consistently. Identity converters (Ok) are appropriate here because the actual per-version migration logic already lives in deserialize_version() / serialize_version().


Suggestions

  • Test coverage: There is no test asserting that the advertised embedded version matches PROTOCOL_VERSION. A simple round-trip test that calls serialize_with_embedded_version(PROTOCOL_VERSION), reads back the embedded version bytes, and asserts equality to PROTOCOL_VERSION would catch this class of regression for all six types.

  • PR description: The description is still template boilerplate. Filling in the motivation (what observable behavior was broken by the mismatch?) would help reviewers and future readers understand the impact.

  • Identity converter intent: Using Ok as a converter is non-obvious. A short inline comment explaining that the length controls the advertised version number, and Ok is used because the actual cross-version logic is already in serialize_version / deserialize_version, would help future maintainers when adding v4.


No concerns on

  • Style and formatting match the surrounding file.
  • No public API surface changes.
  • No security or performance impact.
  • The change is minimal and scoped precisely to the bug.

Generated with Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant