chore: add websocket close logs

[MasterPtato]

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			Dec 11, 2025 10:43pm
rivet-inspector	Ignored	Preview		Dec 11, 2025 10:43pm
rivet-site	Ignored	Preview		Dec 11, 2025 10:43pm
rivetkit-serverless	Skipped			Dec 11, 2025 10:43pm

[MasterPtato]

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: add websocket close logs #3633 👈 (View in Graphite)
• chore: clean up scripts #3630
• fix(guard): use moka cache for in flight reqs #3629
• fix: add debug logs for config loading #3628
• fix(backport): fix serverless #3622
• fix: add serverless backfill #3588 : 1 other dependent PR (#3617 )
• chore: fix runner config creation #3580
• 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: add websocket close logs

Summary

This PR adds logging to the err_to_close_frame function in the guard-core proxy service to track websocket closures and failures.

Code Quality ✅

The change follows good practices:

• Uses structured logging with tracing (following CLAUDE.md guidelines)
• Lowercase log messages as per project conventions
• Uses ?err for structured error logging

Issues & Recommendations

1. Log Message Clarity ⚠️

The current log messages could be more descriptive:

match code {
    CloseCode::Normal => tracing::info!("websocket closed"),
    _ => tracing::error!(?err, "websocket failed"),
}

Recommendation: Add context to help with debugging:

match code {
    CloseCode::Normal => tracing::info!(?code, "websocket closed normally"),
    _ => tracing::error!(?err, ?code, "websocket closed with error"),
}

This would help operators understand:

• Which specific close code was used
• The distinction between normal vs error closures

2. Consider Adding ray_id to Logs 💡

Since the function receives ray_id (used for request tracing), it would be valuable to include it in the logs for correlation:

match code {
    CloseCode::Normal => tracing::info!(?ray_id, "websocket closed normally"),
    _ => tracing::error!(?err, ?ray_id, "websocket closed with error"),
}

This would make it easier to trace specific websocket connections across the distributed system.

3. Log Level for Error Case 🤔

The error case uses tracing::error! which seems appropriate, but consider if this should be warn! for expected error conditions. Looking at the code, these close codes are used for:

• ("ws", "connection_closed") → Normal
• ("ws", "eviction") → Normal
• Everything else → Error

If some of the "error" cases are expected user-triggered closures, warn! might be more appropriate to avoid alert fatigue.

Performance Considerations ✅

• Minimal overhead: just a match statement and log call
• No allocations or expensive operations
• The logging is appropriate for this code path

Security Considerations ✅

• No sensitive data exposed in logs
• Error information is already structured via RivetError
• ray_id is a safe identifier to log

Test Coverage 📝

No tests were added, which is acceptable for this logging change. However, consider:

• Manual verification that logs appear as expected for both normal and error closures
• Check log volume in production to ensure this doesn't create excessive noise

Overall Assessment ✅

Approval Status: Approve with minor suggestions

This is a straightforward improvement that adds useful observability to websocket closures. The logging follows project conventions and will help with debugging production issues.

Suggested improvements (non-blocking):

1. Add ?code to both log statements for better context
2. Add ?ray_id to both log statements for request tracing
3. Consider if all error cases warrant error! level vs warn!

---

Review generated by Claude Code

[graphite-app]

Merge activity

• Dec 12, 12:48 AM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Dec 12, 12:49 AM UTC: CI is running for this pull request on a draft pull request (#3634) due to your merge queue CI optimization settings.
• Dec 12, 12:49 AM UTC: Merged by the Graphite merge queue via draft PR: #3634.