chore(envoy-client): add envoy key tracing context

[NathanFlurry]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[NathanFlurry]

• refactor(metrics): split server metrics crate #5004 : 2 dependent PRs (#5005 , #5006 )
• fix(rivetkit): use unbounded actor channels #5003
• chore(envoy-client): add envoy key tracing context #5002 👈 (View in Graphite)
• chore(rivetkit): rewrite work registry + fix waituntil not preventing sleep #4990
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[railway-app]

🚅 Deployed to the rivet-pr-5002 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
kitchen-sink	❌ Build Failed (View Logs)	Web	May 9, 2026 at 7:33 am
website	😴 Sleeping (View Logs)	Web	May 9, 2026 at 2:54 am
frontend-inspector	❌ Build Failed (View Logs)	Web	May 9, 2026 at 2:44 am
mcp-hub	✅ Success (View Logs)	Web	May 9, 2026 at 2:43 am
ladle	❌ Build Failed (View Logs)	Web	May 9, 2026 at 2:43 am
frontend-cloud	❌ Build Failed (View Logs)	Web	May 9, 2026 at 2:42 am

[claude]

PR Review: chore(envoy-client): add envoy key tracing context

Overview

This PR adds envoy_key as a structured tracing field across envoy-client spans and named spans for long-lived async tasks (envoy_connection, envoy_ws_write, envoy_client, envoy_graceful_shutdown). It is a pure observability improvement with no functional changes.

What Works Well

• Follows project logging conventions: envoy_key = %shared.envoy_key uses structured fields rather than string interpolation in the log message, matching CLAUDE.md.
• Correct .instrument() usage: all futures are instrumented before being handed to tokio::spawn / spawn_local / spawn_detached, so the span context travels with the task correctly.
• Explicit parent capture on detached task: in envoy.rs handle_shutdown, parent: tracing::Span::current() is correctly used so the detached spawn_detached task does not lose its parent span context.
• Log messages remain lowercase, consistent with project conventions.
• Both native.rs and wasm.rs receive the same tracing additions (wasm parity).

Suggestions / Minor Issues

1. Span level mismatch for the root envoy span

envoy_client is created as an info_span! while the child spans (envoy_connection, envoy_ws_write) are debug_span!. This means the root span is always recorded but its children are only recorded at debug level. Consider making all long-lived connection spans the same level (probably debug) unless you specifically want envoy_client to be always-on in production traces.

2. Redundant envoy_key clone in wasm.rs onmessage closure

let envoy_key = shared.envoy_key.clone();
// ...
tracing::warn!(%envoy_key, "received non-binary websocket message");

This closure runs inside the envoy_connection span (via .instrument(span)), so envoy_key is already present on the ambient span. The explicit field on the log line is not harmful, but the clone is unnecessary if you rely on the ambient span field instead.

3. Incomplete coverage in handle.rs

Only start_serverless_actor gets envoy_key added. Other methods on EnvoyHandle that emit logs do not. Fine as an incremental improvement, but a follow-up pass to add it to remaining callsites would complete the picture.

4. shared2 used before move for span creation in native.rs (non-issue, just a note)

shared2 was already being cloned for the async move block; reading envoy_key from it before the move for the span is correct. No change needed.

Summary

Clean, focused change with no correctness concerns. The span-level mismatch between info_span! (root) and debug_span! (children) is the only nit worth addressing before merge. LGTM otherwise.