Skip to content

test(rivetkit): cover bypass fetch header forwarding#4947

Merged
NathanFlurry merged 1 commit intomainfrom
05-04-test_rivetkit_bypass_fetch_header
May 5, 2026
Merged

test(rivetkit): cover bypass fetch header forwarding#4947
NathanFlurry merged 1 commit intomainfrom
05-04-test_rivetkit_bypass_fetch_header

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

This was referenced May 4, 2026
Copy link
Copy Markdown
Member Author

NathanFlurry commented May 4, 2026

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

@claude
Copy link
Copy Markdown
Contributor

claude Bot commented May 4, 2026

Code Review: test(rivetkit): cover bypass fetch header forwarding

Overview

This PR adds two new test cases to remote-engine-client-public-token.test.ts that verify the bypassConnectable header is correctly forwarded through the request pipeline at two layers:

  1. Driver layerRemoteEngineControlClient.sendRequest() with { bypassConnectable: true } sets HEADER_RIVET_BYPASS_CONNECTABLE: "1" on the outbound HTTP request.
  2. Client layerActorHandle.fetch() with { gateway: { bypassConnectable: true } } threads the option through rawHttpFetchsendRequest and produces the same header.

Strengths

  • Good layered coverage. Testing both sendRequest directly and the full handle.fetch() path catches regressions at different abstraction levels.
  • Self-contained mocks. Each test installs its own vi.stubGlobal("fetch", ...) and restores it via afterEach(vi.unstubAllGlobals). No shared state risk.
  • disableMetadataLookup: true is the right choice here — it eliminates the metadata fetch noise so each test only makes one HTTP call and the assertions are unambiguous.
  • Consistent with existing patterns — the fetchCalls accumulator + normalizeRequest helper mirrors the pre-existing tests in the file.
  • No vi.mock / jest.mock — uses vi.fn() for tracking only, which is allowed per project conventions.

Issues and Suggestions

[Minor] Misleading actor name in the second test

The call client.getForId("mockAgenticLoop", "actor-http-bypass") passes "mockAgenticLoop" as the actor type name (first arg to getForId(name, actorId)). That name reads like a real actor type from a different feature area and is unrelated to this test. Something like "test-actor" or "counter" would be less surprising to a future reader.

[Minor] No negative path (header absent when option is omitted)

Both new tests only cover bypassConnectable: true. There is no assertion that the header is absent when the option is omitted or false. The existing tests implicitly cover this, but an explicit expect(actorRequest?.headers.get(HEADER_RIVET_BYPASS_CONNECTABLE)).toBeNull() somewhere would make the contract explicit.

[Nit] Unnecessary optional chaining

After expect(fetchCalls).toHaveLength(1), fetchCalls[0] is guaranteed to exist. The ?. in actorRequest?.headers.get(...) is unnecessary. This matches the pre-existing tests, so it is not a blocker.


Summary

Clean, focused test PR with good coverage of the bypassConnectable forwarding path. All issues above are minor style/completeness nits — the logic is correct and the tests accurately exercise the feature. The misleading actor type name is the most worth fixing before merge.

Generated with Claude Code

@NathanFlurry NathanFlurry force-pushed the 05-04-feat_kitchen_sink_probe_controls branch from 4d9300e to c0b45b3 Compare May 4, 2026 15:36
@NathanFlurry NathanFlurry force-pushed the 05-04-test_rivetkit_bypass_fetch_header branch from 81c9b4d to cc49ff7 Compare May 4, 2026 15:36
@claude
Copy link
Copy Markdown
Contributor

claude Bot commented May 4, 2026

Code Review: test(rivetkit): cover bypass fetch header forwarding

Overview: This PR adds two new tests to remote-engine-client-public-token.test.ts that verify the bypassConnectable flag correctly propagates HEADER_RIVET_BYPASS_CONNECTABLE through both the low-level RemoteEngineControlClient.sendRequest path and the high-level ActorHandle.fetch path.

What is Good:

  • Tests cover real behavior end-to-end. The second test goes from createClient through ActorHandle.fetch, validating gateway option threading in actor-handle.ts and actor-common.ts is wired correctly.
  • No module-level mocking. Uses vi.stubGlobal for fetch, consistent with CLAUDE.md constraints against vi.mock and jest.mock.
  • Consistent with existing test patterns. The normalizeRequest helper, fetchCalls array, and vi.stubGlobal setup mirror surrounding tests faithfully.

Issues and Suggestions:

  1. URL assertion mismatch in the second test

The second test calls handle.fetch('/bypass', ...) which produces path /bypass, then asserts the outgoing URL is https://api.rivet.dev/request/bypass. Those paths do not match. The first test uses new Request('http://actor/request/bypass') which extracts /request/bypass as the path. The second test would produce https://api.rivet.dev/bypass, not /request/bypass. This assertion will fail as written.

  1. fetchCalls length assertion may be incorrect in the second test

Confirm that ActorHandle.fetch with bypassConnectable + getForId does not emit any resolution preflights. disableMetadataLookup: true suppresses metadata fetches, but a resolution step might still occur and cause the toHaveLength(1) assertion to fail.

  1. Missing negative assertion for HEADER_RIVET_TOKEN

Neither test asserts that HEADER_RIVET_TOKEN is absent. Since no token is provided, buildGuardHeaders should not set it. Adding a null assertion would document the intentional absence and guard against regression.

  1. Slightly misleading test name

The second test is titled 'handle fetch forwards bypass connectable to browser request'. The word 'browser' is misleading in a Node/Vitest environment. Consider 'ActorHandle.fetch forwards bypassConnectable header'.

Summary: The intent and structure are correct and cover a real coverage gap. The primary concern is the URL path mismatch in the second test (point 1), which looks like a copy-paste oversight and will cause a test failure. Please verify the path before merging.

Base automatically changed from 05-04-feat_kitchen_sink_probe_controls to main May 5, 2026 14:58
@NathanFlurry NathanFlurry merged commit cc49ff7 into main May 5, 2026
43 of 54 checks passed
@NathanFlurry NathanFlurry deleted the 05-04-test_rivetkit_bypass_fetch_header branch May 5, 2026 14:58
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