Summary
The test comment for vcs_trend_point_round_trips_through_yaml_and_cbor
in src/wire.rs claims VcsTrendPoint and VcsTrend use
#[serde(flatten)] Vcs, but neither struct uses #[serde(flatten)] —
the Vcs block is a nested vcs: key. The comment's CBOR-footgun
rationale (flatten + CBOR) therefore describes a hazard the code does
not actually have.
Location
Evidence
The comment (lines 1064-1067):
/// Issue #702: `VcsTrendPoint` and `VcsTrend` use `#[serde(flatten)]
/// Vcs`, a known CBOR footgun. CBOR is a *written* trend format but was
/// never *read back* in tests — pin the round-trip for both YAML and
/// CBOR.
The actual struct definitions carry no flatten attribute; the Vcs
block is a plain nested field:
pub struct VcsTrendPoint {
pub as_of: i64,
pub vcs: Vcs, // nested key "vcs", not flattened
}
rg -n flatten src/wire.rs returns only the comment itself — there is
no #[serde(flatten)] anywhere in the file. The module docs and the
VcsTrendPoint / VcsTrend doc comments elsewhere correctly describe
the metrics as sitting "under a nested vcs key (issue #684)", directly
contradicting this test comment.
Expected Behavior
The comment should describe the actual serialized shape: a nested vcs
object (not a flattened set of keys). The round-trip-test rationale can
keep the "written-but-never-read-back CBOR" motivation, but must not
attribute it to #[serde(flatten)].
Actual Behavior
The comment asserts a #[serde(flatten)] design that does not exist,
misleading a reader about both the wire shape and the specific CBOR
hazard being guarded against. (The #[serde(flatten)]+CBOR footgun is
real in general — adjacently-tagged/flattened maps can break CBOR
round-trips — but it does not apply here because no field is flattened.)
Impact
Documentation-only. A maintainer reading the test to understand the
serialized VCS-trend shape (or deciding whether flatten-related CBOR
caveats apply when editing these structs) is actively misinformed. No
runtime behavior is affected.
Resolution
Corrected the wire.rs test comment: VcsTrendPoint/VcsTrend use a nested vcs key, not serde(flatten). Kept the write-only-untested CBOR round-trip rationale. Commit a7e35ad.
Summary
The test comment for
vcs_trend_point_round_trips_through_yaml_and_cborin
src/wire.rsclaimsVcsTrendPointandVcsTrenduse#[serde(flatten)] Vcs, but neither struct uses#[serde(flatten)]—the
Vcsblock is a nestedvcs:key. The comment's CBOR-footgunrationale (flatten + CBOR) therefore describes a hazard the code does
not actually have.
Location
src/wire.rs:1064-1067Evidence
The comment (lines 1064-1067):
The actual struct definitions carry no
flattenattribute; theVcsblock is a plain nested field:
rg -n flatten src/wire.rsreturns only the comment itself — there isno
#[serde(flatten)]anywhere in the file. The module docs and theVcsTrendPoint/VcsTrenddoc comments elsewhere correctly describethe metrics as sitting "under a nested
vcskey (issue #684)", directlycontradicting this test comment.
Expected Behavior
The comment should describe the actual serialized shape: a nested
vcsobject (not a flattened set of keys). The round-trip-test rationale can
keep the "written-but-never-read-back CBOR" motivation, but must not
attribute it to
#[serde(flatten)].Actual Behavior
The comment asserts a
#[serde(flatten)]design that does not exist,misleading a reader about both the wire shape and the specific CBOR
hazard being guarded against. (The
#[serde(flatten)]+CBOR footgun isreal in general — adjacently-tagged/flattened maps can break CBOR
round-trips — but it does not apply here because no field is flattened.)
Impact
Documentation-only. A maintainer reading the test to understand the
serialized VCS-trend shape (or deciding whether flatten-related CBOR
caveats apply when editing these structs) is actively misinformed. No
runtime behavior is affected.
Resolution
Corrected the wire.rs test comment: VcsTrendPoint/VcsTrend use a nested vcs key, not serde(flatten). Kept the write-only-untested CBOR round-trip rationale. Commit a7e35ad.