Skip to content

fix(rivetkit): preserve engine bind defaults - #5643

Open
eersnington wants to merge 1 commit into
rivet-dev:mainfrom
eersnington:stack/fix-rivetkit-preserve-engine-bind-defaults-rqsvztrk
Open

fix(rivetkit): preserve engine bind defaults#5643
eersnington wants to merge 1 commit into
rivet-dev:mainfrom
eersnington:stack/fix-rivetkit-preserve-engine-bind-defaults-rqsvztrk

Conversation

@eersnington

Copy link
Copy Markdown

Description

That port was hard-coded to 6420 in the TypeScript registry config, even if you passed an endpoint on a different port. Result: the client waits on the port you asked for, the Engine listens on 6420, nothing connects.

The Rust side already had the right logic: use the bind port if set, otherwise use the endpoint's port. The TypeScript config just never let the bind port be unset (enginePort had .default(6420)), so that fallback never ran.

The fix: leave the bind host and port unset unless you configure them, and only apply 127.0.0.1:6420 when RivetKit builds its own local Engine URL.

What changes:

  • Nothing set: still 6420. Unchanged.
  • Explicit enginePort: used as before. Unchanged.
  • Only an endpoint: the Engine now listens on that endpoint's port. This never worked before.

Production is not affected. Deployed apps connect to a remote Engine and never spawn one. This only matters for local dev and for tests that spawn an Engine on a random port, which is how it was found.

Four lines in registry/config/index.ts plus a constructor test.

Note for test authors: a spawned Engine keeps running after its parent exits, and the next process reuses it if it is healthy at the same address. Now that random ports work, a test that picks a new port each run gets a new Engine each run. Such tests should set RIVETKIT_STORAGE_PATH per run and stop their Engine on teardown, otherwise the previous run's Engine keeps the database locked.

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?

# Before, RivetKit asked for port 54250:

$ pnpm exec vitest run tests/napi-runtime-integration.test.ts
target=rivetkit_napi::registry message="serving native registry" endpoint=http://127.0.0.1:54250/
target=rivetkit_engine_process message="spawned engine process (intentionally orphaned, will outlive this process)" pid=11147
[Error: {"code":"health_check_failed","group":"engine","message":"Engine health check failed after 14 attempts: error sending request for url (http://127.0.0.1:54250/health)"}]
 × native NAPI runtime integration > runs a TS actor through registry, NAPI, core, envoy, and engine

# The Engine's own log from that run shows where it bound:

 message="loaded config" config="Root { ... guard: Some(Guard { host: Some(127.0.0.1), port: Some(6420), ...
 message="HTTP server listening on 127.0.0.1:6420"

# After:

$ pnpm exec vitest run tests/napi-runtime-integration.test.ts
 ✓ native NAPI runtime integration > runs a TS actor through registry, NAPI, core, envoy, and engine  6825ms
 Test Files  1 passed (1)

message="loaded config" config="Root { ... guard: Some(Guard { host: Some(127.0.0.1), port: Some(54308), ...
message="HTTP server listening on 127.0.0.1:54308"

# Also:

$ pnpm exec vitest run tests/registry-constructor.test.ts
 Tests  6 passed (6)

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

@eersnington
eersnington force-pushed the stack/fix-rivetkit-preserve-engine-bind-defaults-rqsvztrk branch from c1f2e1f to 2b600fd Compare September 2, 2026 21:15
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