fix: emit UpdateEvent::BroadcastEmitted telemetry events

[sanity]

Problem

The UpdateEvent::BroadcastEmitted event type is defined in crates/core/src/tracing.rs and has full telemetry serialization support in telemetry.rs, but it is never actually emitted by the protocol code during update broadcasts.

Evidence: The telemetry database has 307,154 update_broadcast_received events and 45,035 update_broadcast_applied events, but zero update_broadcast_emitted events.

Impact

Without broadcast_emitted events, the telemetry dashboard cannot:

• Trace the actual broadcast tree (who sends to whom)
• Distinguish between direct broadcasts and indirect propagation
• Identify bottleneck peers that are slow to forward

The from_peer field is also absent from broadcast_received events (only to_peer is populated), making it impossible to reconstruct the propagation path.

Suggested Fix

Add NetEventLog::route_event calls with UpdateEvent::BroadcastEmitted at the point where update broadcasts are sent to subscribers in the update operation handler. The event type already has:

• Full field definitions (id, upstream, broadcast_to, broadcasted_to, key, state_hash)
• Telemetry serialization (telemetry.rs:1208-1219)
• State verifier support

It just needs to be wired up in the actual broadcast sending code.

[AI-assisted - Claude]

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-bug (98% confidence)
• P-medium (90% confidence)
• E-easy (80% confidence)
• A-networking (90% confidence)

Reasoning: The report describes existing telemetry event types that are implemented but never emitted by the protocol, which is a bug (missing behavior). It impacts telemetry visibility for update broadcasts but doesn't appear to block releases or cause data loss, so medium priority is appropriate. The fix is limited to adding event emissions at broadcast points and wiring existing serialization, which should be a small, well-scoped code change (easy). The issue pertains to broadcast behavior and telemetry in the networking/update propagation code, so A-networking is the relevant area.

Previous labels: none

If these labels are incorrect, please update them. This helps improve the auto-labeling system.

[majiayu000]

Hi, I've been looking into this and traced the root cause.

Proposed approach: 1. Locate UpdateEvent::BroadcastEmitted definition in crates/core/src/tracing.rs to understand required fields (id, upstream, broadcast_to, broadcasted_to, key, state_hash). 2. Find the update broadcast sending code in the update operation handler (likely in crates/core/src/operations/update.rs or similar). 3. Add NetEventLog::route_event calls with BroadcastEmitted at the point where broadcasts are sent to subscribers. 4. Follow existing patterns from BroadcastReceived/BroadcastApplied emissions as templates. 5. Run cargo check and cargo test.

I'll open a draft PR shortly. Happy to adjust based on your preference.

[majiayu000]

I'd like to work on this. The fix involves:

1. Adding an update_broadcast_emitted() constructor to NetEventLog in tracing.rs (following the pattern of update_broadcast_received and update_broadcast_applied)
2. Emitting the event in the simulation path (broadcast_state_to_peers) after the send loop
3. Emitting the event in the production path (handle_broadcast_state_change) after enqueuing targets

Will open a PR shortly.