fix(rivetkit): stop hibernating actor connections by default

[eersnington]

• Actor connections from .connect() (actions and events) now follow canHibernateWebSocket, which defaults to false, instead of always hibernating. can_hibernate in rivetkit-core/src/registry/mod.rs no longer returns true for the actor-connect path. This matches the docs, which already describe WebSocket hibernation as off by default.
• A connection that does not hibernate closes when its actor sleeps, and the client reconnects. An actor keeps the old behavior by opting in:

actor({
	options: { canHibernateWebSocket: true },
	// ...
});

• A caller that leaves mid-request no longer keeps the actor awake. When Gateway3 drops the request future, DisconnectOnDrop removes the connection, during onConnect or the action. The action itself still finishes.
• Driver fixtures that test hibernation now opt in.

---

This is part 1 of 2 in a stack:

•  2  fix(rivetkit): remove the connection of an aborted HTTP action #5836
•  1  fix(rivetkit): stop hibernating actor connections by default #5835 👈

[railway-app]

This PR was not deployed automatically as @eersnington does not have access to the Railway project.

In order to get automatic PR deploys, please add @eersnington to your workspace on Railway.

[claude]

Review

The change is small and the intent is clear. Dropping the is_actor_connect_path shortcut in can_hibernate makes .connect() follow canHibernateWebSocket, which matches the docs. DisconnectOnDrop is a good way to stop an abandoned request from keeping the actor awake. I haven't built the PR or run the tests.

Potential issues

1. Behavior change for existing actors. Every actor that uses .connect() and relied on hibernation now closes its connections on sleep, and clients reconnect. That is a reasonable fix, but it is user-visible. Call it out in the release notes, and check for other fixtures, examples, or docs that implicitly depend on hibernating connections. Only the fixtures in this diff were updated.
2. DisconnectOnDrop::drop uses RuntimeSpawner::spawn. If the guard is dropped outside a runtime context, for example during runtime teardown, the spawn could panic on native builds. Probably fine given the actor task context, but it deserves a quick check or a comment.
3. If the future is dropped mid-emit_connection_open, the spawned disconnect(None) will run disconnect hooks, including onDisconnect, for a connection whose onConnect never completed. Please confirm that is intended, and that disconnect is safe for a connection that was never counted. inc_connections_total only runs after the guard is disarmed.
4. Minor style: in create_conn, opening.disarm() is called in both the error branch and the success path. Disarm once right after emit_connection_open returns, then branch on the result.

Tests

• The new no-hibernation test and the two Gateway3 abort tests cover the main paths, and the vi.waitFor calls have justifying comments as required.
• Nothing covers the DisconnectOnDrop cancellation path on the HTTP action and queue paths in http.rs at the core level. A Rust test under tests/ would help.
• The abort tests use a fixed waitFor(SLEEP_TIMEOUT + 250). Make sure it isn't flaky in CI, and consider an event-driven wait.

[the-company-company]

🟠 2 medium-severity findings

_{Reviewed commit 061ce65.}

[eersnington]

@claude what can you do if i tag you?