Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

State and test what two daemon versions must agree on during a rolling update

Open
  • Is something wrong?
#67 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
distributed-systems, documentation, release, testing

Research direction

Start with the handshake paths in crates/pacer-transport/src/grpc.rs and crates/pacer-daemon/src/peer.rs, then inspect SLOT_FORMAT_VERSION in crates/pacer-cache/src/slot.rs and the existing release documentation. Define the compatibility behavior and metric for unsupported protocol versions, document slot-format and chunk-size changes, and add a CI test using the previous release image that reads, writes, and invalidates through both versions.

Written by the indexing model from the issue text.

Description

enhancement rust

A rolling update runs the old and new daemon versions side by side until the last node has restarted. Ring placement is safe across versions because ADR-0014 freezes the hash. Nothing states or tests what else the two versions must agree on.

Peers exchange protocol_version in Handshake (crates/pacer-proto/proto/pacer/v1/peer.proto), but both sides only log it (GrpcTransport in crates/pacer-transport/src/grpc.rs, PacerPeer::handshake in crates/pacer-daemon/src/peer.rs). A change to a peer RPC that protobuf cannot absorb would show up as failed fetches or invalidations during the roll, not as a refused peer.

The disk tier has the same question on upgrade. The slot format is versioned (SLOT_FORMAT_VERSION, crates/pacer-cache/src/slot.rs), and a slot of another version reads as free, which is safe but empties the node's disk tier. Release notes do not currently say when that happens.

Proposed:

  • a written rule in the docs: a release interoperates with the previous release; peer protocol changes only add fields; a change that cannot be additive bumps protocol_version and ships across two releases;
  • act on the version in the handshake: a peer with an unsupported version is treated as unavailable, so requests fall back as they do for any unavailable peer, and a metric counts it;
  • release notes state when a release changes SLOT_FORMAT_VERSION or chunk_size, since either empties the disk tier on upgrade;
  • a CI test that runs the previous release's image next to the current build and reads, writes and invalidates through both.
Dominant language
Rust
Stars
16
Forks
1
Avg merge
7h 19m
Merged PRs (30d)
29

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from aws-samples/sample-pacer

All issues in aws-samples/sample-pacer

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.