fix(runner): do not send websocket close on tunnel shutdown since pegboard-runner takes care of this

[NathanFlurry]

No description provided.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-serverless	Ready	Preview	Comment	Nov 6, 2025 5:37am

3 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
rivet-cloud	Ignored			Nov 6, 2025 5:37am
rivet-inspector	Ignored	Preview		Nov 6, 2025 5:37am
rivet-site	Ignored	Preview		Nov 6, 2025 5:37am

[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(agents): add graphite-commit agent for conventional commits #3394
• fix(rivetkit): only trigger onStateChange and inspector updates for actor state changes #3393
• fix(rivetkit): reject all waiters in SinglePromiseQueue #3392
• fix(rivetkit): fix hibernatable websocket last seen message index to be i64 instead of u64 #3391
• fix(rivetkit): gracefully call _onStop for actors on runner shutdown #3390
• fix(rivetkit): fix initial hibernation state always being overridden with msgIndex of -1 #3389
• fix(rivetkit): fix missing duplex in nextjs in development #3388
• chore(runner): add safeguard against duplicate sockets #3387
• chore(runner): explicitly stringify tunnel messages, commands, and events #3386
• fix(runner): do not send websocket close on tunnel shutdown since pegboard-runner takes care of this #3385 👈 (View in Graphite)
• fix(rivetkit): fix actors trying to sleep after stop started #3384
• chore(runner): rename webSocketId -> requestId #3383
• chore(runner): add explicit close reason when client runner shuts down #3382
• fix(guard): fix 1006 when client closes ws connection #3381
• chore(runner): add child logger with runner id #3380
• chore(rivetkit): remove warnings for graceful runner shtudown #3379
• fix(gateway): fix gc logic #3378
• fix: boot dupe runners #3377
• fix(rocksdb): fix txn conflict checker #3376
• 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: Fix WebSocket Close on Tunnel Shutdown

Overview

This PR addresses an issue where the TypeScript runner was attempting to send WebSocket close messages during tunnel shutdown, even though the Pegboard WebSocket is already closed at that point. The fix appropriately delegates teardown logic to pegboard-runner.

Code Quality & Best Practices

Strengths:

• ✅ Good separation of concerns: __closeWithoutCallback() method clearly indicates its special purpose with the double underscore prefix
• ✅ Helpful inline comments explaining the rationale, especially the reference to pegboard-runner code (line 79 in tunnel.ts)
• ✅ Proper error handling with the new RunnerShutdownError class to distinguish shutdown errors from other failures
• ✅ The fix aligns with the existing architecture where pegboard-runner handles cleanup (as shown in lib.rs:157)

Issues Found:

1. Typo in Log Message (tunnel.ts:428)

   this.log?.debug({ msg: "catught runner shutdown error" });

   Should be: "caught runner shutdown error"

2. Missing Trigger of Close Event (tunnel.ts:81-82)

   // TODO: Trigger close event, but do not send anything over the tunnel
   ws.__closeWithoutCallback(1000, "ws.tunnel_shutdown");

   The TODO comment suggests the close event should be triggered, but __closeWithoutCallback() still fires the close event via this.#fireEvent("close", closeEvent) (websocket-tunnel-adapter.ts:235). This comment may be misleading or the implementation may not match the intent. Please clarify:

   • If the close event should be fired → Remove or update the TODO
   • If it shouldn't be fired → Add a parameter to prevent firing the event

3. Inconsistent Parameter Ordering (websocket-tunnel-adapter.ts:204-209)
   The closeInner() method has parameters in the order: code, reason, retry, callback. Consider reordering to group related parameters: code, reason, callback, retry for better readability.

Potential Bugs

Silent Error Suppression (tunnel.ts:427-428)

if (error instanceof RunnerShutdownError) {
    this.log?.debug({ msg: "catught runner shutdown error" });
}

During shutdown, if a fetch handler throws a RunnerShutdownError, the error is logged at debug level but the response is never sent. This could lead to:

• Pending requests hanging if the error occurs before a response is sent
• No indication to the caller that the request failed due to shutdown

Recommendation: Verify that this is the intended behavior. If the pegboard WebSocket is already closed, sending a response would fail anyway, but it might be worth adding a comment explaining why no response is sent.

Performance Considerations

✅ No performance concerns. The changes are minimal and occur during shutdown, which is not a hot path.

Security Concerns

✅ No security issues identified. The changes improve correctness by preventing attempts to send data over a closed WebSocket.

Test Coverage

⚠️ Missing Test Coverage

I don't see any test files in this PR. Given that this fixes a specific shutdown race condition, consider adding tests for:

1. Shutdown Behavior Test: Verify that tunnel.shutdown() doesn't attempt to send WebSocket close messages
2. RunnerShutdownError Handling: Ensure pending requests are properly rejected with RunnerShutdownError during shutdown
3. WebSocket State Test: Confirm that __closeWithoutCallback() updates the WebSocket state but doesn't invoke the callback

Example test structure:

describe('Tunnel shutdown', () => {
  it('should not send WebSocket close messages during shutdown', async () => {
    // Setup tunnel with mock WebSocket
    // Call shutdown()
    // Verify no tunnel messages were sent
  });
  
  it('should reject pending requests with RunnerShutdownError', async () => {
    // Setup tunnel with pending request
    // Call shutdown()
    // Verify request was rejected with RunnerShutdownError
  });
});

Additional Notes

Good Context Reference: The link to pegboard-runner code (line 79) is helpful but uses a specific commit hash (00d4f6a...). Consider if this should reference a stable branch instead, or ensure the referenced code doesn't change.

Summary

This is a solid fix that addresses a real issue in the shutdown sequence. The main action items are:

1. Fix typo: "catught" → "caught"
2. Clarify TODO comment: Does the close event need to be fired or not?
3. Consider adding tests: Especially for the shutdown race condition
4. Review error handling: Confirm that silently suppressing RunnerShutdownError is the intended behavior

Overall: Approve with minor fixes recommended ✅

[pkg-pr-new]

More templates

• example-ai-agent
• example-background-jobs
• example-better-auth-external-db
• example-bots
• chat-room
• example-cloudflare-workers
• example-cloudflare-workers-hono
• example-counter
• example-counter-serverless
• example-crdt
• example-cursors
• example-cursors-raw-websocket
• example-database
• example-deno
• example-sqlite
• example-elysia
• example-express
• example-freestyle
• example-game
• example-hono
• example-hono-bun
• example-hono-react
• example-kitchen-sink
• example-next-js
• example-rate
• example-raw-fetch-handler
• example-raw-websocket-handler
• example-raw-websocket-handler-proxy
• example-react
• starter
• example-stream
• example-sync
• example-tenant
• example-trpc
• example-workflows

@rivetkit/actor

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/actor@3385

@rivetkit/cloudflare-workers

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/cloudflare-workers@3385

@rivetkit/core

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/core@3385

@rivetkit/db

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/db@3385

@rivetkit/framework-base

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/framework-base@3385

@rivetkit/next-js

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/next-js@3385

@rivetkit/react

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/react@3385

rivetkit

pnpm add https://pkg.pr.new/rivet-dev/rivet/rivetkit@3385

@rivetkit/sql-loader

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/sql-loader@3385

@rivetkit/engine-runner

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/engine-runner@3385

@rivetkit/engine-runner-protocol

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/engine-runner-protocol@3385

commit: 7a186f6

[claude]

PR Review: Fix WebSocket Close Handling on Runner Shutdown

Summary

This PR fixes a race condition where the TypeScript runner was attempting to send WebSocket close messages over the Pegboard tunnel after the connection had already been closed by pegboard-runner. The fix introduces proper shutdown handling that avoids sending messages over a closed connection while still properly cleaning up local state.

Code Quality ✅

Good Practices:

• Well-documented changes with clear comments explaining the rationale
• Proper error handling with custom RunnerShutdownError class
• Clean separation of concerns with the new __closeWithoutCallback method
• Links to relevant code in comments for context

Improvements Made:

• Introduces RunnerShutdownError to distinguish shutdown scenarios from other errors
• Adds callback parameter to closeInner to control whether the close callback is invoked
• Properly silences RunnerShutdownError in error handlers to avoid noise during shutdown

Potential Issues 🔍

1. Typo in Log Message (line 428):

this.log?.debug({ msg: "catught runner shutdown error" });

Should be: "caught runner shutdown error"

2. TODO Comment Needs Clarification (line 81-82):

// TODO: Trigger close event, but do not send anything over the tunnel
ws.__closeWithoutCallback(1000, "ws.tunnel_shutdown");

The current implementation does trigger the close event via closeInner. If this TODO is still relevant, it should be clarified. If the implementation is correct, the TODO should be removed or updated.

3. Missing Close Event Trigger:
The shutdown() method calls __closeWithoutCallback which sets the ready state and fires the close event. However, the comment suggests uncertainty about whether the close event should be triggered. This should be verified:

• If the close event should fire: The current implementation is correct
• If the close event should NOT fire: Need to add a parameter to skip event firing entirely

Architecture Considerations 💡

Shutdown Flow:
The changes correctly recognize that pegboard-runner handles teardown at line 157 of lib.rs, which prevents sending messages over a closed connection. The separation of concerns is:

• pegboard-runner: Handles WebSocket connection lifecycle
• TypeScript runner: Handles local state cleanup

This is a good architectural decision.

Error Handling Pattern:
The use of RunnerShutdownError to distinguish shutdown from other errors is clean. However, consider:

• Should pending requests receive a more specific error than just rejection?
• Are there scenarios where client code needs to distinguish between shutdown vs other failures?

Performance Considerations ⚡

• No concerns: The changes are minimal and don't introduce performance issues
• Proper cleanup of intervals, maps, and pending requests prevents memory leaks

Security Concerns 🔒

• No security issues identified
• Proper state management prevents use-after-close scenarios
• Close codes and reasons are handled appropriately

Test Coverage 📋

Current Tests:

• Found tests/lifecycle.test.ts but unable to determine if it covers shutdown scenarios
• No tests visible for the WebSocket tunnel adapter shutdown path

Recommendations:

1. Add test case for runner shutdown with active WebSockets
2. Add test case for runner shutdown with pending HTTP requests
3. Verify that RunnerShutdownError is properly caught and silenced
4. Test that WebSocket close events are properly fired during shutdown

Suggested Changes

Required:

1. Fix typo: "catught" → "caught" on line 428

Recommended:

1. Clarify or remove the TODO comment on line 81-82
2. Add explicit tests for shutdown scenarios
3. Consider adding a log statement when WebSockets are closed during shutdown for observability

Verdict: ✅ Approve with Minor Fixes

This is a solid fix for a real race condition. The approach is sound and the implementation is clean. The only required change is fixing the typo. The recommended changes would improve code quality but are not blockers.

Impact: Low risk - This prevents errors during shutdown without changing happy-path behavior.

---

Review generated by Claude Code

[claude]

Code Review

Summary

This PR addresses a WebSocket cleanup issue during runner shutdown by preventing the TypeScript runner from sending close messages over a WebSocket that's already been closed by pegboard-runner. The approach uses a new custom error type and a flag to control callback behavior.

Positive Aspects

✅ Good problem identification: The PR correctly identifies that the Pegboard WS is already closed during shutdown, so attempting to send messages is pointless
✅ Clear documentation: Comments explaining the rationale are helpful (lines 58-59, 75-79 in tunnel.ts)
✅ Proper separation of concerns: The new __closeWithoutCallback method cleanly separates the "close without sending" logic

Issues & Suggestions

1. Typo in error handling (tunnel.ts:428)

this.log?.debug({ msg: "catught runner shutdown error" });

Should be: "caught runner shutdown error"

2. Incomplete TODO comment (tunnel.ts:81-82)

// TODO: Trigger close event, but do not send anything over the tunnel
ws.__closeWithoutCallback(1000, "ws.tunnel_shutdown");

The TODO says "Trigger close event" but the code already does trigger the close event (via closeInner → state update → #fireEvent). This TODO should either be:

• Removed if the implementation is complete, or
• Clarified if there's additional work needed

3. Error handling logic may be overly broad (tunnel.ts:427-436)

The RunnerShutdownError is only thrown during shutdown() when rejecting pending requests, but the catch block in #handleRequestStart catches it for all errors. While this works, consider:

• Is there any risk of masking other legitimate errors that should be logged?
• Should the debug log include more context about which request was affected?

Recommendation:

if (error instanceof RunnerShutdownError) {
    this.log?.debug({ 
        msg: "caught runner shutdown error",
        requestId: idToStr(requestId),
        actorId: req.actorId 
    });
} else {
    // ... existing error handling
}

4. API design concern: Double-underscore prefix

The new __closeWithoutCallback method uses the double-underscore prefix convention, which in this codebase appears to indicate "internal/private" methods. However:

• It's only called from Tunnel.shutdown()
• The naming is a bit awkward ("without callback" is implementation detail)

Consider:

• Could shutdown() directly call closeInner(code, reason, false, false)?
• Or would a more semantic name like __shutdownClose() be clearer?

5. Race condition consideration

During shutdown, the code rejects all pending requests with RunnerShutdownError and closes all WebSockets. Is there any risk that:

• New requests could arrive between clearing the maps and the WS fully closing?
• The order of operations (reject requests → close WebSockets) matters?

The code looks correct, but a comment explaining that pegboard-runner has already closed the connection (so no new messages can arrive) would be helpful.

6. Test coverage

No test changes are included. Consider adding tests for:

• Shutdown behavior with pending requests
• Shutdown behavior with active WebSockets
• Verification that no messages are sent during shutdown

Performance & Security

✅ No performance concerns - the changes are minimal and in cleanup paths
✅ No security concerns - properly handles shutdown without attempting invalid operations

Best Practices (per CLAUDE.md)

✅ Uses structured logging with tracing-style approach (though this is TypeScript, not Rust)
✅ Error handling follows the pattern of custom error types
⚠️ Minor: The debug log on line 428 should use lowercase per guidelines: "caught runner shutdown error"

Recommendation

Approve with minor changes: Fix the typo, clarify/remove the TODO, and consider adding basic test coverage for the shutdown path.

The core logic is sound and addresses a real issue with attempting to send messages over a closed WebSocket during shutdown.

[claude]

Code Review for PR #3385

Summary

This PR fixes an issue where the TypeScript runner was incorrectly attempting to send WebSocket close messages over the tunnel during shutdown, even though the pegboard-runner WebSocket is already closed at that point. The changes properly handle the shutdown sequence by introducing a new error type and a close method that doesn't send messages over the tunnel.

Positive Aspects

✅ Good separation of concerns: The new RunnerShutdownError class makes it explicit when errors occur due to runner shutdown vs other failures
✅ Clear comments: The inline comments explain why the WebSocket close is not sent (pegboard-runner handles it)
✅ Proper state management: The __closeWithoutCallback method correctly updates internal state without triggering network operations
✅ Link to source: The GitHub link to pegboard-runner code (line 79) helps reviewers understand the cross-component behavior

---

Issues Found

1. Typo in Error Handling (tunnel.ts:428)

Severity: Low

this.log?.debug({ msg: "catught runner shutdown error" });

Should be "caught" not `"catught""

Location: engine/sdks/typescript/runner/src/tunnel.ts:428

---

2. TODO Comment Without Close Event Firing (tunnel.ts:81-82)

Severity: Medium - Potential Bug

// TODO: Trigger close event, but do not send anything over the tunnel
ws.__closeWithoutCallback(1000, "ws.tunnel_shutdown");

The comment says "Trigger close event" but looking at websocket-tunnel-adapter.ts:200-236, the __closeWithoutCallback method:

• Sets callback = false which skips the tunnel callback ✅
• But still fires the close event via this.#fireEvent("close", closeEvent) at line 235 ✅

So the TODO comment is misleading - the close event is being triggered. Either:

1. Remove/update the TODO comment since it's already doing what it says, or
2. If close events shouldn't be fired during shutdown, this is a bug

Question for author: During runner shutdown, should the WebSocket adapters fire close events to user code, or should they silently close? The current implementation fires the event.

Location: engine/sdks/typescript/runner/src/tunnel.ts:81-82

---

3. Inconsistent Error Handling Pattern

Severity: Low

The RunnerShutdownError is caught and logged at debug level in two places:

• tunnel.ts:427-429 - HTTP request handler
• No explicit handling for WebSocket shutdown errors in #handleWebSocketOpen (line 666)

For consistency, if WebSocket handlers throw RunnerShutdownError, they should also handle it gracefully like HTTP requests do.

---

4. Missing Type Safety for Close Codes

Severity: Low

ws.__closeWithoutCallback(1000, "ws.tunnel_shutdown");

WebSocket close codes have specific meanings per RFC 6455. Consider:

• Using a constant like NORMAL_CLOSURE = 1000 for clarity
• Using code 1001 (Going Away) which semantically matches "server is shutting down"
• Documenting why 1000 was chosen

Location: engine/sdks/typescript/runner/src/tunnel.ts:82

---

Architectural Considerations

5. Race Condition Risk

Severity: Medium

The shutdown sequence (tunnel.ts:57-85):

1. Clears GC interval
2. Rejects all pending requests with RunnerShutdownError
3. Closes all WebSockets

If new requests arrive between steps 1-3, they could be accepted but never properly cleaned up. Consider:

• Setting a #isShuttingDown flag at the start of shutdown()
• Checking this flag in handleTunnelMessage to reject new work
• This would make the shutdown more robust

---

6. Memory Leak Prevention

Severity: Low

The shutdown clears:

• #actorPendingRequests ✅
• #actorWebSockets ✅
• #gcInterval ✅

But doesn't clear:

• #pendingTunnelMessages ❓

Is this intentional? If the tunnel is shutting down, pending acks will never arrive, so this map could be cleared too.

---

Testing Concerns

7. No Tests for New Behavior

Severity: High

The PR doesn't include tests for:

• RunnerShutdownError being thrown and caught correctly
• __closeWithoutCallback not invoking the callback
• Shutdown sequence closing all WebSockets without sending messages
• Proper state transitions during shutdown

Recommendation: Add tests to tests/lifecycle.test.ts covering:

test('shutdown rejects pending requests with RunnerShutdownError', async () => {
  // Setup runner with pending request
  // Call shutdown()
  // Assert request rejected with RunnerShutdownError
});

test('shutdown closes websockets without tunnel messages', async () => {
  // Setup runner with active WebSocket
  // Mock tunnel message sending
  // Call shutdown()
  // Assert no tunnel messages sent
  // Assert WS in CLOSED state
});

---

Security Considerations

✅ No security issues identified. The changes are internal refactoring and don't expose new attack surfaces.

---

Performance Considerations

✅ Performance impact is minimal/positive:

• Avoiding unnecessary message sends during shutdown reduces work
• No new allocations or loops introduced

---

Recommendations Summary

Must Fix:

1. Fix typo "catught" → "caught" (tunnel.ts:428)

Should Fix:
2. Clarify TODO comment about close event triggering (tunnel.ts:81)
3. Add test coverage for shutdown behavior
4. Consider clearing #pendingTunnelMessages in shutdown()

Consider:
5. Add #isShuttingDown flag to prevent race conditions
6. Add constants for WebSocket close codes
7. Consistent error handling for RunnerShutdownError in WebSocket paths

---

Verdict

Overall: Approve with Minor Changes ✅

The core fix is sound - not sending WebSocket close messages over an already-closed tunnel prevents errors. However, the typo should be fixed and test coverage should be added before merging.

The TODO comment needs clarification, and the architectural improvements (shutdown flag, pending message cleanup) would make the code more robust, though they're not blockers for this PR.

---

Review generated by Claude Code following CLAUDE.md conventions

[claude]

PR Review: Fix runner websocket close on tunnel shutdown

Summary

This PR addresses a race condition where the TypeScript runner was sending WebSocket close messages over the tunnel during shutdown, even though the pegboard WebSocket connection had already been closed. The fix introduces a new error type and a conditional close method to prevent sending messages when the runner is shutting down.

Code Quality & Best Practices

Positive aspects:

• Clear separation of concerns with the new RunnerShutdownError class
• Good use of internal methods (__closeWithRetry, __closeWithoutCallback) to differentiate between normal and shutdown-specific close behaviors
• Appropriate use of comments explaining why certain behaviors occur

Issues identified:

1. Typo in error message (tunnel.ts:428)

   this.log?.debug({ msg: "catught runner shutdown error" });

   Should be "caught" instead of "catught"

2. TODO comment suggests incomplete implementation (tunnel.ts:81-82)

   // TODO: Trigger close event, but do not send anything over the tunnel
   ws.__closeWithoutCallback(1000, "ws.tunnel_shutdown");

   The TODO suggests the implementation may not be complete. The close event should be triggered for client-side cleanup, but the comment indicates uncertainty about whether this is happening correctly.

3. Inconsistent error handling pattern: The RunnerShutdownError is silently ignored with only a debug log. Consider whether this should be handled differently or if the debug message provides sufficient visibility for troubleshooting.

Potential Bugs

1. Incomplete WebSocket lifecycle management: The __closeWithoutCallback method changes the ready state and fires the close event, but bypasses the callback. This could lead to:

   • WebSockets not being properly removed from tracking maps in some edge cases
   • Actor WebSocket tracking (actor.webSockets) potentially not being cleaned up

2. Race condition potential: If shutdown() is called while requests are actively being processed in #handleRequestStart, the RunnerShutdownError rejection happens but the finally block still executes. This appears correct, but the timing could be tricky.

Architecture & Design

Good design decisions:

• The three-parameter approach (retry, callback) in closeInner provides clear control over behavior
• Using a specific error type (RunnerShutdownError) makes the intent explicit

Concerns:

• The proliferation of close methods (close, __closeWithRetry, __closeWithoutCallback) increases API surface complexity
• Consider whether a single close method with an options object might be cleaner:

  close(code?: number, reason?: string, options?: { retry?: boolean, callback?: boolean })

Performance Considerations

• No significant performance issues identified
• The changes are in shutdown paths which are not performance-critical

Security Concerns

• No security issues identified
• Proper cleanup during shutdown is actually a security benefit (prevents resource leaks)

Test Coverage

Missing test coverage:

• No tests visible for the shutdown behavior
• Should add tests for:
  1. Verifying that WebSocket close messages are NOT sent during runner shutdown
  2. Verifying that pending requests are properly rejected with RunnerShutdownError
  3. Verifying that the close event is triggered on WebSockets during shutdown
  4. Testing the race condition between active request handling and shutdown

Recommendations

1. Fix the typo on line 428 of tunnel.ts
2. Add tests for the shutdown behavior to prevent regression
3. Clarify the TODO or implement the missing functionality for triggering close events
4. Consider refactoring the close method API to use an options object instead of multiple methods
5. Document the shutdown flow more thoroughly - add a comment explaining the coordination between pegboard-runner and the TypeScript runner during shutdown
6. Verify WebSocket cleanup: Ensure that actor.webSockets tracking is properly cleaned up when using __closeWithoutCallback

Related Questions

• The comment references a specific commit hash in the pegboard-runner code. As the codebase evolves, this link may break. Consider using a permalink or documenting the behavior more explicitly.
• Should there be any metrics or observability around shutdown errors to track how often this code path is hit?

---

Overall, this is a good fix for a specific race condition, but it would benefit from better test coverage and some minor polish around error messages and API design.

[graphite-app]

Merge activity

• Nov 6, 5:47 AM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Nov 6, 5:48 AM UTC: CI is running for this pull request on a draft pull request (#3395) due to your merge queue CI optimization settings.
• Nov 6, 5:50 AM UTC: Merged by the Graphite merge queue via draft PR: #3395.