fix(runtime): preserve event channel metadata compatibility (cherry-pick #12708) - #12840
Conversation
Signed-off-by: PeaBrane <yanrpei@gmail.com> (cherry picked from commit a487897) Signed-off-by: Thomas Montfort <tjmontfort12@gmail.com>
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| channel.insert( | ||
| "namespace".to_string(), | ||
| serde_json::Value::String(scope.namespace().to_string()), | ||
| ); | ||
| channel.insert( | ||
| "component".to_string(), | ||
| // v1.2 represented namespace-scoped publishers with an empty component. | ||
| serde_json::Value::String(scope.component().unwrap_or("").to_string()), | ||
| ); |
There was a problem hiding this comment.
🔍 Endpoint-scoped channels are downgraded to component identity, losing endpoint distinction for v1.2 readers
add_legacy_event_channel_fields maps every scope onto only namespace/component, so an EventScope::Endpoint channel becomes indistinguishable from a component-scoped one in the v1.2 wire shape (EventScope::component() returns the endpoint's component, lib/runtime/src/discovery/mod.rs:264-270). Two endpoint-scoped channels of the same component/topic on one worker share the same instance_id, so a v1.2 reader sees two map entries with identical legacy identity (namespace, component, topic, instance_id) but different transports; v1.2 keyed its own map by EventChannelInstanceId::to_path() (ns/comp/topic/id) and its subscribers group by discovery instance, so one publisher may be shadowed. Worth confirming whether the current runtime ever registers two endpoint-scoped channels with the same topic under one component, since that is the only scenario in which the downgrade is ambiguous. The reverse direction is also inherently lossy: upgraded v1.2 records always become EventScope::Component, so a current subscriber querying with EventChannelQuery::endpoint_topic(...) will not match a v1.2 publisher's record even for the same logical channel.
Was this helpful? React with 👍 or 👎 to provide feedback.
| /// Accept the pre-scope event-channel shape at the Kubernetes DWM boundary. | ||
| pub(super) fn deserialize_metadata(mut data: serde_json::Value) -> Result<DiscoveryMetadata> { | ||
| add_current_event_channel_scopes(&mut data)?; | ||
| Ok(serde_json::from_value(data)?) | ||
| } |
There was a problem hiding this comment.
🔍 Compatibility shim applies only to the Kubernetes DWM path, not the KV-store discovery backend
The legacy field emission/reconstruction lives entirely in build_cr/deserialize_metadata for the Kubernetes CR boundary. lib/runtime/src/discovery/kv_store.rs serializes DiscoveryInstance directly (serde_json::to_vec(&instance) at lib/runtime/src/discovery/kv_store.rs:445, from_slice at :195) and derives keys from EventChannelInstanceId::from_path at :208, so etcd/KV-store deployments mixing v1.2 and current binaries remain incompatible for event channels. If mixed-version rollout is only supported on Kubernetes this is fine; otherwise the shim is incomplete.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
🎯 Code Coverage (details) 🔗 Commit SHA: 3aeaee4 | Docs | Datadog PR Page | Give us feedback! |
3 participants
Summary
release/1.4.0.EventChannelmetadata by reconstructing legacynamespaceandcomponentfields as the current internal scope.scopeso v1.2 frontends can deserialize DWM records from current workers.Original PR
a487897b7ab27527764fdf2d44cf5c90d29432ed3aeaee410779259e5db7bf4d5ba15b9f8cfaffc4Release adaptation
Clean cherry-pick with no conflicts or release-specific code changes.
Validation
cargo test -p dynamo-runtime discovery::kube::crd::tests --lib— 4 passedcargo fmt --all -- --check— passeduvx pre-commit run --from-ref origin/release/1.4.0 --to-ref HEAD— passedgit diff --check origin/release/1.4.0..HEAD— passedRelated Issues