[blocked] chore(deps): bincode 1.3->3.0 (smg-mesh) — 3.0.0 is a tombstone compile_error release

[slin1237]

[blocked] bincode 1.3 -> 3.0 (crates/mesh) cannot be adopted

Assigned unit: bump bincode 1.3 -> 3.0 in crates/mesh/Cargo.toml, fix CRDT/gossip serialization breakage, pass pre-commit, open PR.

Status: BLOCKED — the target version is a non-functional tombstone release.

Root cause

bincode 3.0.0 (the only 3.x on crates.io, and the latest published version) is not a real release. Its entire src/lib.rs is:

compile_error!("https://xkcd.com/2347/");

Its README.md states:

Bincode is now unmaintained. Due to a doxxing and harassment incident, development on bincode has ceased. No further releases will be published on crates.io. ... this final release is being published containing only this README, as well as a lib.rs containing only a compiler error, to inform potential users of the maintenance status of this crate.

The published 3.0.0 crate contains only README.md, LICENSE.md, and a lib.rs that is a single compile_error!. There is no API surface — no Encode/Decode, no config builder, no serde compat module. Any crate that depends on bincode = "3.0" fails to compile by design.

Reproduction

Compiling the published 3.0.0 source directly:

$ rustc --edition 2021 --crate-name bincode --crate-type lib \
    ~/.cargo/registry/src/.../bincode-3.0.0/src/lib.rs
error: https://xkcd.com/2347/
 --> .../bincode-3.0.0/src/lib.rs:1:1
  |
1 | compile_error!("https://xkcd.com/2347/");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to 1 previous error

cargo build -p smg-mesh with the bump applied fails identically once it reaches the bincode crate.

Adopting the bump as specified is therefore impossible, and the procedure forbids pinning back to an old version to dodge a breaking change — but here there is simply nothing to migrate to. This requires an orchestrator decision, hence a draft.

Why this is left as a 3.0 diff

This draft intentionally keeps bincode = "3.0" in crates/mesh/Cargo.toml so the attempt and the failure are visible. The branch does not compile (by design of the upstream tombstone) and must not be merged.

Recommended path: retarget to bincode 2.0.1

The full version list (from the crates.io index) shows the last real major after 1.3.3 is 2.0.0 / 2.0.1 (both published, non-yanked). 2.x is exactly the rewrite described in the unit's breaking-change notes: Encode/Decode derives + a config builder replacing serialize/deserialize + Options, with bincode::serde compat helpers for serde-derived types.

If retargeted to 2.0.1, the mesh migration is well-scoped to two files:

• crates/mesh/src/crdt_kv/operation.rs
  • OperationLog::to_bytes / from_bytes (bincode::serialize/deserialize over the serde-derived OperationLog).
  • decode_counter_payload (bincode::deserialize::<i64> and ::<HashMap<String, i64>>).
• crates/mesh/src/crdt_kv/epoch_max_wins.rs
  • encode_shard (bincode::serialize) and decode_shard, which currently uses DefaultOptions::new().with_fixint_encoding().allow_trailing_bytes().with_limit(64 KiB).

Wire-format caveat (must preserve): in bincode 1.3, both bincode::serialize and decode_shard use fixint + little-endian (1.3's free serialize/deserialize default to with_fixint_encoding). RateLimitShard bytes are gossiped between nodes and persisted, so a 2.x migration must use bincode::config::legacy() (fixint, little-endian, no limit) for encode_shard/OperationLog, and a fixint + little-endian config with a 64 KiB read limit for decode_shard, to keep the gossip/stored format byte-compatible across a rolling upgrade. The serde-derived types would migrate via bincode::serde::encode_to_vec / decode_from_slice (the serde feature), not the native Encode/Decode derives, to avoid changing the encoding.

Requested decision

Please either (a) retarget this unit to bincode 2.0.1, or (b) pick a maintained successor (the upstream README points to wincode as a bincode-compatible drop-in, and postcard/rkyv otherwise). I did not unilaterally switch the target version.

Verification performed

• Inspected the published bincode 3.0.0 package contents (README + tombstone lib.rs).
• Reproduced the compile_error! via direct rustc compile of 3.0.0.
• Enumerated all bincode versions from the local crates.io index cache to confirm 2.0.1 is the newest real major and 3.0.0 is the only 3.x.
• DCO sign-off present; no functional code changes (only the version requirement, which is why CI will fail to build — expected for this blocked draft).

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 0e95504e-39ca-43dc-be00-1b7b9b3ab7fd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch deps/bincode

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request updates the bincode dependency version in crates/mesh/Cargo.toml from 1.3 to 3.0. Feedback was provided to correct this change, as bincode 3.0 is a tombstone release that will cause compilation failures, and migrating to version 2.0.1 or reverting to 1.3 is recommended instead.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Using bincode = "3.0" will break compilation because bincode 3.0.0 is a tombstone release that only contains a compile_error!. To resolve this, you should either revert to 1.3 or migrate to 2.0.1 (the latest functional release supporting the new Encode/Decode API and config builder) or use a maintained alternative like wincode.

Suggested change

	bincode = "3.0"
	bincode = "2.0.1"

[claude]

👋 The PR description doesn't fully follow
PULL_REQUEST_TEMPLATE.md:

• Missing header: ## Description
• Missing header: ### Problem
• Missing header: ### Solution
• Missing header: ## Changes
• Missing header: ## Test Plan

Please update the PR description so reviewers have the context they need.

[claude]

Per REVIEW.md, dependency version bumps with no code changes are in the skip list. This PR changes only crates/mesh/Cargo.toml (one line: bincode "1.3" → "3.0"), with no accompanying code changes.

The PR description thoroughly documents that bincode 3.0.0 is a tombstone release (compile_error! only) and proposes retargeting to 2.0.1 as the path forward. No code-level issues to flag.

Summary: 0 🔴 Important · 0 🟡 Nit · 0 🟣 Pre-existing