Skip to content

fix(rivetkit): route raw request fetches to actors#4781

Merged
NathanFlurry merged 1 commit intomainfrom
driver-fixes/raw-request-routing
Apr 27, 2026
Merged

fix(rivetkit): route raw request fetches to actors#4781
NathanFlurry merged 1 commit intomainfrom
driver-fixes/raw-request-routing

Conversation

@NathanFlurry
Copy link
Copy Markdown
Member

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

Copy link
Copy Markdown
Member Author

NathanFlurry commented Apr 26, 2026

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

@claude
Copy link
Copy Markdown

claude Bot commented Apr 26, 2026

PR Review: fix(rivetkit): route raw request fetches to actors

Overview

This PR introduces a /request prefix path that routes HTTP requests directly to an actor's onRequest handler, bypassing the built-in framework routes (/action/, /queue/, /metadata, /health, /). It also relocates the inline #[cfg(test)] mod tests from src/registry/http.rs to tests/modules/registry_http.rs, aligning with the CLAUDE.md rule requiring Rust tests to live under tests/.


Code Quality

Positive changes:

  • RegistryHttpRoute enum is a clear improvement over the old Option<FrameworkHttpRoute> — the two routing outcomes (Framework vs UserRawRequest) are now explicit and exhaustively matched. The use of matches!(route, RegistryHttpRoute::Framework(_)) at the error-path check correctly replaces the old is_some() guard.
  • Extracting rearm_sleep_after_request from a closure into a free function removes the duplication and makes the call sites easier to read.
  • Splitting dispatch into handle_user_request_fetch vs handle_framework_fetch cleanly separates the two routing outcomes.
  • Test relocation follows CLAUDE.md conventions. The two new tests (request_prefix_detection_matches_normalization, classifier_keeps_framework_and_user_routing_separate) directly exercise the routing logic added here.

Issues / Observations

1. Sleep timer not rearmed on successful user raw requests (pre-existing, but now more visible)

In handle_fetch, framework routes always call rearm_sleep_after_request (success or error). For UserRawRequest, rearm_sleep_after_request is called only in the Err arm inside handle_user_request_fetch. The successful path returns without rearming the sleep timer. This was true before this PR as well, but the new enum-dispatched structure makes the asymmetry easier to see. If this is intentional (e.g. the sleep timer for raw requests is managed elsewhere), a short comment explaining why would prevent future confusion.

2. Test name slightly misleads for the /requestfoo case

request_prefix_detection_matches_normalization asserts:

assert!(matches!(
    RegistryHttpRoute::from_paths("/requestfoo", "/requestfoo").expect("route should decode"),
    RegistryHttpRoute::UserRawRequest
));

/requestfoo lands in UserRawRequest via the fallthrough _ => Ok(Self::UserRawRequest) arm, not via the /request prefix check (since "foo" doesn't start with / or ?). The test is correct, but the assertion is testing a different code path than the rest of the cases in that function. Splitting it into a separate test named something like non_request_prefix_falls_through_to_user_raw_request would make the intent clearer.

3. normalize_actor_request_path imported in tests but not in the diff

The new test module imports normalize_actor_request_path from super, but that function doesn't appear in the diff. This is fine if it pre-existed in http.rs, but it should be verified that it's pub(super) or otherwise accessible, and that it behaves consistently with the from_paths prefix logic (which the new tests are checking).

4. Error message artifact — trailing period removed

-  "message": "Incoming message too long."
+  "message": "Incoming message too long"

The test struct #[error("message", "incoming_too_long", "Incoming message too long")] also omits the period, and the JSON test assertion checks the no-period form. This is consistent, but it's a semantic change to a published error artifact — worth confirming this won't break clients comparing against the old literal string.


Minor Nits

  • The from_paths method correctly prioritizes the /request prefix check before framework route matching on normalized_path. This prevents /request/action/foo from accidentally matching the framework action handler. The test classifier_keeps_framework_and_user_routing_separate covers this well.
  • The actor_id structured log field in the error branch of handle_user_request_fetch is now actor_id = instance.actor_id rather than a bare actor_id variable captured from the outer scope. This is consistent with the tracing conventions in CLAUDE.md.

Summary

The routing logic is correct, the refactoring is clean, and the test migration follows project conventions. The main item worth a follow-up or clarification is whether the missing rearm_sleep_after_request on the success path of UserRawRequest is intentional — a comment at the call site or in the extracted method would help future readers. Everything else is nit-level.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 26, 2026

Preview packages published to npm

Install with:

npm install rivetkit@pr-4781

All packages published as 0.0.0-pr.4781.f4470fa with tag pr-4781.

Engine binary is shipped via @rivetkit/engine-cli on linux-x64-musl, linux-arm64-musl, darwin-x64, and darwin-arm64. Windows users should use the release installer or set RIVET_ENGINE_BINARY.

Docker images:

docker pull rivetdev/engine:slim-f4470fa
docker pull rivetdev/engine:full-f4470fa
Individual packages
npm install rivetkit@pr-4781
npm install @rivetkit/react@pr-4781
npm install @rivetkit/rivetkit-napi@pr-4781
npm install @rivetkit/workflow-engine@pr-4781

@NathanFlurry NathanFlurry changed the base branch from driver-fixes/db-migrate-before-lifecycle to graphite-base/4781 April 26, 2026 20:54
@NathanFlurry NathanFlurry force-pushed the driver-fixes/raw-request-routing branch from a4b1187 to 0d560ef Compare April 26, 2026 20:54
@NathanFlurry NathanFlurry changed the base branch from graphite-base/4781 to driver-fixes/refresh-runner-config-after-envoy-connect April 26, 2026 20:54
@NathanFlurry NathanFlurry force-pushed the driver-fixes/refresh-runner-config-after-envoy-connect branch from 9b12a58 to 57ee9a8 Compare April 27, 2026 01:06
@NathanFlurry NathanFlurry force-pushed the driver-fixes/raw-request-routing branch from 0d560ef to 2a7294b Compare April 27, 2026 01:06
@NathanFlurry NathanFlurry changed the base branch from driver-fixes/refresh-runner-config-after-envoy-connect to graphite-base/4781 April 27, 2026 01:10
@NathanFlurry NathanFlurry force-pushed the driver-fixes/raw-request-routing branch from 2a7294b to 158a1f1 Compare April 27, 2026 01:17
@NathanFlurry NathanFlurry changed the base branch from graphite-base/4781 to driver-fixes/refresh-runner-config-after-envoy-connect April 27, 2026 01:17
Base automatically changed from driver-fixes/refresh-runner-config-after-envoy-connect to main April 27, 2026 07:13
@NathanFlurry NathanFlurry merged commit 25dd07c into main Apr 27, 2026
19 of 22 checks passed
@NathanFlurry NathanFlurry deleted the driver-fixes/raw-request-routing branch April 27, 2026 07:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant