chore(pegboard-runner): log runner messages

[NathanFlurry]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

4 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
rivet-cloud	Ignored			Nov 21, 2025 2:31am
rivet-inspector	Ignored			Nov 21, 2025 2:31am
rivet-site	Ignored			Nov 21, 2025 2:31am
rivetkit-serverless	Skipped			Nov 21, 2025 2:31am

[NathanFlurry]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• chore(pegboard-runner): log runner messages #3514 👈 (View in Graphite)
• fix(runner-protocol): fix decoding gateway & req id from req id instead of message id #3513
• fix(runner-protocol): add noop converters for v1 -> v3 #3512
• chore(engine): upgrade vbare 0.0.4 #3511
• chore: remove msg id parts from protocol, move id utils to runner protocol crate #3508
• docs: runner lifecycle #3510
• chore(rivetkit): buffer outbound tunnel messages #3509
• fix(engine): ensure first keepalive tick is not skipped to prevent timeout on ws hibernation #3507
• chore(examples): add counter-next-js example #3506
• feat(cloudflare-workers): add createInlineClient #3466
• fix(rivetkit): uri encode actor ids to fix cloudflare workers actor id with generation #3504
• chore(rivetkit): fix lockfile #3503
• chore(rivetkit): make action cancelled error more descriptive #3500
• fix(gateway): prevent gc from removing hibernating in flight req, check actor started after sub when hibernating #3505
• fix(pb): add ability to timeout force resceduling pending state #3502
• fix(pb): stop actors from destroying on goingaway #3501
• fix(pegboard-gateway): ping hibernating requests both during open hws connections and during hibernation #3498 : 1 other dependent PR (#3499 )
• fix(rivetkit): fix graceful runner shutdown #3497
• fix(pegboard-gateway): write hws immediately on socket hibernate #3496
• chore(rivetkit): fix hibernation implementation #3494
• fix(tunnel): implement ping pong #3491 : 1 other dependent PR (#3475 )
• chore(pegboard-gateway): add new message id format & add deprecated tunnel ack #3492
• chore(pegboard-gateway): remove TunnelAck #3488
• chore(engine-runner): remove echo close on ToClientWebSocketClose #3487
• chore(rivetkit): implement new hibernating ws protocol #3464 : 1 other dependent PR (#3452 )
• fix(actor-kv): fix listing keys #3484
• fix(guard): handle actor stopped during ws/req #3481
• chore: rename retry -> hibernate in runner protocol #3473
• fix(udb): update backoff algo #3469
• chore: write/update docs #3468
• chore: add debug scripts #3467
• main

---

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

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

[claude]

PR Review: chore(pegboard-runner): log runner messages

Summary

This PR adds debug logging for runner messages in both directions of the WebSocket communication:

• tunnel_to_ws_task.rs: Logs messages being sent from the tunnel to the client
• ws_to_tunnel_task.rs: Logs messages received from the client

✅ Positives

1. Follows logging conventions: Uses structured logging with tracing::debug!(?var, "message") as recommended in CLAUDE.md
2. Appropriate log level: Uses debug level, which is correct for message tracing in production
3. Symmetric logging: Adds logging on both message send and receive paths, providing complete visibility
4. Helpful for debugging: Will aid in troubleshooting WebSocket communication issues

📝 Code Quality Observations

Log message consistency:
The two log messages use slightly different phrasing:

• Line 121 in tunnel_to_ws_task.rs: "sending runner message to client"
• Line 68 in ws_to_tunnel_task.rs: "received runner message from client"

Placement difference:

• In ws_to_tunnel_task.rs (line 68), the log is placed after deserialization, so it logs the parsed message structure
• In tunnel_to_ws_task.rs (line 121), the log is placed before serialization, so it also logs the parsed message structure

This is actually good - both log the structured message data rather than raw bytes, making debugging easier.

🔍 Potential Considerations

1. Log volume at debug level:
In high-traffic scenarios, these debug logs could generate significant volume. This is acceptable since:

• Debug logs are typically disabled in production
• When enabled for troubleshooting, this is exactly the information needed
• The log level is appropriate for this type of tracing

2. Sensitive data logging:
The logs use ? debug formatting which will dump the entire message structure. Consider:

• Review if any protocol::ToClient or protocol::ToServer variants contain sensitive data (tokens, credentials, PII)
• If sensitive data exists, may want to implement custom Debug or use selective field logging

3. Existing log coverage:
I notice there are already logs at different points:

• Line 41-44 in tunnel_to_ws_task.rs: Logs payload length when receiving from pubsub
• Line 51-54 in ws_to_tunnel_task.rs: Logs at trace level for binary data

The new logs complement these by showing the parsed protocol messages, which is valuable.

🧪 Test Coverage

Note: No test files were found for the pegboard-runner package. While this PR only adds logging (low risk), consider:

• Integration tests that verify message flow could benefit from these new log statements
• The logs could be used in tests to verify correct message handling

🔐 Security Considerations

Low risk: Adding debug logging doesn't introduce security vulnerabilities. However:

• Ensure debug logs are not exposed in production logging systems that may be accessible to unauthorized parties
• If messages contain sensitive data, consider adding sanitization or using #[serde(skip_debug)] on sensitive fields

⚡ Performance Considerations

Minimal impact: Debug logging with lazy evaluation means:

• When debug logging is disabled, only a boolean check is performed
• Message formatting only occurs if debug level is enabled
• No performance concerns for this change

📊 Summary

Recommendation: ✅ Approve

This is a straightforward, well-implemented logging improvement that:

• Follows the project's logging conventions from CLAUDE.md
• Uses appropriate log levels
• Provides valuable debugging information
• Has minimal performance impact
• Introduces no security vulnerabilities

The only minor suggestion would be to verify that the protocol message types don't contain sensitive data that shouldn't be logged. Otherwise, this is ready to merge.

---

Review generated via Claude Code

[graphite-app]

Merge activity

• Nov 21, 2:40 AM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Nov 21, 2:42 AM UTC: CI is running for this pull request on a draft pull request (#3515) due to your merge queue CI optimization settings.
• Nov 21, 2:43 AM UTC: Merged by the Graphite merge queue via draft PR: #3515.