Skip to content

chore(rivetkit): impl inspector token#4722

Closed
NathanFlurry wants to merge 1 commit into04-23-chore_disable_auth_on_serverlessfrom
04-23-chore_rivetkit_impl_inspector_token
Closed

chore(rivetkit): impl inspector token#4722
NathanFlurry wants to merge 1 commit into04-23-chore_disable_auth_on_serverlessfrom
04-23-chore_rivetkit_impl_inspector_token

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 24, 2026

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

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

@claude
Copy link
Copy Markdown

claude Bot commented Apr 24, 2026

PR #4722 Review: chore(rivetkit): impl inspector token

Summary: This PR implements inspector token initialization for the Rust rivetkit-core actor startup path. It generates a cryptographically random 32-byte URL-safe base64 token, persists it to KV key [3] (matching the TypeScript KEYS.INSPECTOR_TOKEN layout), and skips generation when the RIVET_INSPECTOR_TOKEN env var override is already set.


Critical Bug: Tests No Longer Cover the Real Code Path

The test changes in tests/modules/inspector.rs swap RIVET_INSPECTOR_TOKEN for _RIVET_TEST_INSPECTOR_TOKEN in the env lock/set/remove calls, but InspectorAuth::verify and init_inspector_token in auth.rs still read RIVET_INSPECTOR_TOKEN (the INSPECTOR_TOKEN_ENV constant). After this change, the three auth tests that set _RIVET_TEST_INSPECTOR_TOKEN can never influence code that reads RIVET_INSPECTOR_TOKEN, so the env-token priority branch and the env-token guard in init_inspector_token are effectively untested.

The intent appears to be isolating tests from the real env var, but the constant used in the source code was not updated to match. Either the tests should keep using RIVET_INSPECTOR_TOKEN (and accept that running in an environment with that var set could affect results), or the source constant should be updated to _RIVET_TEST_INSPECTOR_TOKEN with a #[cfg(test)] alias. The current state breaks the test invariant silently.

Recommendation: Revert the env var name change in the tests so they match INSPECTOR_TOKEN_ENV = RIVET_INSPECTOR_TOKEN, or add a #[cfg(test)] override constant in auth.rs and update both the constant and tests together.


Security: rand::thread_rng() Should Be OsRng for Security-Sensitive Tokens

rand::thread_rng() is seeded from the OS but may buffer entropy and has historically had subtle seeding issues across fork boundaries. For a security-sensitive secret like an inspector auth token, the preferred choice is rand::rngs::OsRng directly, which reads from the OS CSPRNG on every call with no internal state:

use rand::RngCore;
use rand::rngs::OsRng;

fn generate_inspector_token() -> String {
    let mut bytes = [0u8; INSPECTOR_TOKEN_BYTES];
    OsRng.fill_bytes(&mut bytes);
    URL_SAFE_NO_PAD.encode(bytes)
}

The codebase already uses getrandom directly in rivetkit-sqlite for security-sensitive RNG, which is consistent precedent.


Performance: Token Init Not Batched With Startup Preload

The new call is placed between persist_state and restore_hibernatable_connections_with_preload in start_actor. This runs on every actor wake, meaning the KV read in init_inspector_token is an extra round-trip on every wake. The TypeScript implementation avoids this by batching the inspector token KV get into the preload map and the write into a WriteCollector flushed in a single batch. The Rust path currently does two individual KV operations (get + conditional put) on every actor wake with no batching. Not a correctness issue, but worth tracking as a follow-up.


Minor Issues

  • Comment typo (registry/inspector.rs): // TODO: Impelment when ready - Impelment should be Implement. Per CLAUDE.md style, comments should be complete sentences: // TODO: Implement traces endpoint when ready.
  • Visibility: init_inspector_token is exported as pub from crate::inspector. Since it is only called from actor::task, consider pub(crate) to limit surface area.
  • Missing startup perf log: The TypeScript implementation wraps initializeInspectorToken in startup timing. The Rust path adds no corresponding tracing span. Consider adding a tracing::debug! span consistent with other startup phases.

Summary

Severity Issue
Critical Test env var renamed to _RIVET_TEST_INSPECTOR_TOKEN but source still reads RIVET_INSPECTOR_TOKEN - auth tests no longer cover the env-token code path
Security Use OsRng instead of thread_rng() for the inspector token
Performance KV get+put not batched with startup preload; extra round-trip on every actor wake
Minor Typo in TODO comment: Impelment
Minor init_inspector_token could be pub(crate)
Minor Missing startup perf log for new init phase

@github-actions
Copy link
Copy Markdown
Contributor

Preview packages published to npm

Install with:

npm install rivetkit@pr-4722

All packages published as 0.0.0-pr.4722.75d4644 with tag pr-4722.

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-75d4644
docker pull rivetdev/engine:full-75d4644
Individual packages
npm install rivetkit@pr-4722
npm install @rivetkit/react@pr-4722
npm install @rivetkit/rivetkit-napi@pr-4722
npm install @rivetkit/workflow-engine@pr-4722

@NathanFlurry NathanFlurry force-pushed the 04-23-chore_rivetkit_impl_inspector_token branch from 3b9f382 to d88d866 Compare April 24, 2026 09:52
@NathanFlurry NathanFlurry mentioned this pull request Apr 24, 2026
11 tasks
@NathanFlurry NathanFlurry force-pushed the 04-23-chore_disable_auth_on_serverless branch from 54eeddd to f700e8a Compare April 24, 2026 10:19
@NathanFlurry NathanFlurry force-pushed the 04-23-chore_rivetkit_impl_inspector_token branch from d88d866 to 136e91f Compare April 24, 2026 10:19
@NathanFlurry NathanFlurry force-pushed the 04-23-chore_rivetkit_impl_inspector_token branch from 136e91f to f06fea6 Compare April 24, 2026 10:32
@NathanFlurry NathanFlurry force-pushed the 04-23-chore_disable_auth_on_serverless branch from f700e8a to c2c77e5 Compare April 24, 2026 10:32
@NathanFlurry NathanFlurry force-pushed the 04-23-chore_rivetkit_impl_inspector_token branch from f06fea6 to c1a28bb Compare April 24, 2026 11:48
@NathanFlurry NathanFlurry force-pushed the 04-23-chore_disable_auth_on_serverless branch from c2c77e5 to 8bc569f Compare April 24, 2026 11:48
@NathanFlurry NathanFlurry force-pushed the 04-23-chore_rivetkit_impl_inspector_token branch from c1a28bb to bec342f Compare April 24, 2026 12:14
@NathanFlurry NathanFlurry force-pushed the 04-23-chore_rivetkit_impl_inspector_token branch from bec342f to c4929c6 Compare April 24, 2026 12:32
@NathanFlurry
Copy link
Copy Markdown
Member Author

Landed in main via stack-merge fast-forward push. Commits are in main; closing to match.

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