refactor(rivetkit-rust): route client through query-based gateway instead of get_or_create resolution

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/actors

• #5631 refactor(rivetkit-rust): route client through query-based ga … 👈
• #5627 fix(rivetkit): retry get_or_create as get on allocated datac …
• main

Get stack: forklift get 5631
Push local edits: forklift submit
Merge when ready: forklift merge 5631

_{change swlkkvuy}

[railway-app]

🚅 Deployed to the actors-pr-5631 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
kitchen-sink	😴 Sleeping (View Logs)	Web	Sep 1, 2026 at 11:38 pm
frontend-cloud	😴 Sleeping (View Logs)	Web	Sep 1, 2026 at 11:31 pm
website	❌ Build Failed (View Logs)	Web	Sep 1, 2026 at 11:30 pm
frontend-inspector	😴 Sleeping (View Logs)	Web	Sep 1, 2026 at 11:27 pm
mcp-hub	✅ Success (View Logs)	Web	Sep 1, 2026 at 11:21 pm
ladle	✅ Success (View Logs)	Web	Sep 1, 2026 at 11:21 pm

[claude]

Review

Solid, well-scoped refactor. It brings the Rust client to parity with the TS client's query-based gateway routing (rvt-namespace/rvt-method/rvt-key/... query params, matching engine/packages/guard/src/routing/actor_path.rs), removing an extra round-trip to /actors for getForKey/getOrCreateForKey before every action/queue-send/fetch/websocket call.

Code quality / correctness

• GatewayTarget enum + the gateway_target()/build_gateway_url() split is clean, and every match on ActorQuery/GatewayTarget enumerates variants explicitly (no _ => fallback), consistent with the repo's enum-matching convention.
• Create queries still resolve eagerly via create_actor() before returning GatewayTarget::Direct, and GetForId stays direct, correctly scoped to only defer resolution for the two key-based queries.
• The query-string merge logic in build_query_gateway_url (handling path that may already contain ?, e.g. from raw fetch/websocket paths) looks correct and is exercised by the updated raw_fetch/raw_websocket tests (source=rust param merged with rvt-* params).
• Removing the actor id/target WS subprotocols and x-rivet-actor/x-rivet-target headers for Query targets is correctly gated behind matches!(target, GatewayTarget::Direct), and the tests assert their absence.
• resolve_actor_id is kept and still correctly used by the public ActorHandle::resolve() API (which needs an actual concrete actor id back), so it isn't dead code.

Minor observations (non-blocking)

• ActorConnection's query field is never rewritten after connecting (unlike ActorHandleStateless, which re-resolves every call). Since try_connect()/connect_driver() re-invoke gateway_target() on every reconnect, a connection opened from a Create query will call create_actor() again on each reconnect attempt, and a getOrCreateForKey connection will simply re-query the gateway with the original key (fine). This matches pre-PR behavior exactly (previously resolve_actor_id was also called fresh on every reconnect), so it's not a regression introduced here, just flagging in case it's worth a follow-up to cache the resolved id for Create after the first connect.
• debug!(?target, "opening WebSocket connection to actor via gateway") in ws.rs will now Debug-print the full ActorQuery (including key/input) for query-based targets, not just an actor id string. Low risk at debug level, but worth being aware of if input can carry sensitive payloads.
• The URL-embedded token (@token path segment for direct targets, rvt-token query param for query targets) predates this PR, so extending the query-param token to real data-plane requests isn't a new issue, just an existing pattern now used more widely.

Test coverage

Good, tests/bare.rs was updated meaningfully rather than just patched to compile: it asserts the actual gateway path/query params (rvt-namespace, rvt-method, rvt-key) reach the server, and explicitly asserts the absence of x-rivet-target/x-rivet-actor headers and rivet_target.actor/rivet_actor.* WS protocols for query-routed requests. The removed /actors PUT routes/handlers are correctly dropped since key-based flows no longer hit that endpoint.

No blocking issues found.