chore(rivetkit): add `WebSocketContext` and `RequestContext` #3427

NathanFlurry · 2025-11-10T00:18:37Z

No description provided.

vercel · 2025-11-10T00:18:43Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-serverless	Ready	Preview	Comment	Nov 13, 2025 2:48am

3 Skipped Deployments

Project	Deployment	Preview	Updated (UTC)
rivet-cloud	Ignored		Nov 13, 2025 2:48am
rivet-inspector	Ignored	Preview	Nov 13, 2025 2:48am
rivet-site	Ignored	Preview	Nov 13, 2025 2:48am

NathanFlurry · 2025-11-10T00:19:07Z

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

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

_{An organization admin has enabled the Graphite Merge Queue in this repository.} _{Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.}

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

claude · 2025-11-10T00:20:32Z

PR Review: Add `WebSocketContext` and `RequestContext`

Overview

This PR introduces specialized context classes (RequestContext and WebSocketContext) for raw HTTP and WebSocket handlers, providing better API ergonomics and clearer separation of concerns. The changes improve type safety by exposing the conn object directly while maintaining access to actor-level functionality.

✅ Positives

Improved API Design: The new context classes provide a cleaner, more intuitive interface for handler functions. Separating request/WebSocket contexts from the general ActorContext makes the API more discoverable and easier to use.
Better Type Safety: By having dedicated context types, developers get better IDE autocomplete and type checking for request vs WebSocket handlers.
Consistent Pattern: The implementation follows the existing ActionContext and ActorContext pattern, maintaining consistency across the codebase.
Good Documentation: All new classes and methods have proper JSDoc comments with type parameter descriptions.
Test Coverage: The changes update existing test fixtures, ensuring the new API works correctly.
Proper Encapsulation: Uses private fields (#actorContext) and delegates to the underlying ActorContext, following good OOP principles.

🔍 Code Quality Observations

Good Practices:

Hard tabs are used consistently (per CLAUDE.md conventions)
Proper use of TypeScript's private fields syntax
Type-only imports where appropriate
Exports properly added to the module index

Architecture:

The delegation pattern to ActorContext is clean and maintainable
Connection is now exposed directly via public readonly conn, which improves usability

🤔 Suggestions & Considerations

1. Code Duplication Between Context Classes

The RequestContext and WebSocketContext classes are nearly identical (183 lines each), with only the class name and documentation comments differing. This creates maintenance overhead.

Consideration:

Could these share a common base class or use composition to reduce duplication?
If they're intentionally kept separate for future divergence, this is acceptable but should be documented.

Example approach (if desired):

abstract class BaseHandlerContext<...> {
  #actorContext: ActorContext<...>;
  public readonly conn: Conn<...>;
  
  // All shared getters and methods here...
}

export class RequestContext<...> extends BaseHandlerContext<...> {
  // Request-specific methods (if any in the future)
}

export class WebSocketContext<...> extends BaseHandlerContext<...> {
  // WebSocket-specific methods (if any in the future)
}

However, if the plan is to add specialized methods to each context type in the future, the current approach is fine.

2. Missing Return Value in `config.ts`

In rivetkit-typescript/packages/rivetkit/src/actor/config.ts:431, the signature was updated but there's a slight inconsistency:

onRequest?: (
  c: RequestContext<...>,
  request: Request,
) => Response | Promise<Response>;

The return type looks correct, but the implementation in instance/mod.ts:661 checks:

if (!response) {
  throw new errors.InvalidRequestHandlerResponse();
}

This suggests Response cannot be nullable, which is correct. However, the JSDoc says:

@returns A Response object to send back, or void to continue with default routing

This comment appears to be outdated - the type signature doesn't allow void. Should either:

Update the JSDoc to remove "or void to continue with default routing"
OR update the type to allow void | undefined if that's intentional

3. Removed `opts` Parameter

The onRequest handler previously had an empty opts: {} parameter that was removed. While this simplifies the API now, if you anticipate needing options in the future, you might want to keep it (even empty) for API stability. However, removing it is cleaner if options aren't needed.

Similarly, onWebSocket now has opts: { request: Request } which is good - it provides the upgrade request context.

4. Missing Tests for New Context Classes

While the test fixtures were updated to use the new types, I don't see explicit tests for:

Verifying that RequestContext.conn is properly set
Verifying that WebSocketContext.conn is properly set
Testing that all delegated methods work correctly

Recommendation: Add integration tests that verify:

// In a test actor
onRequest(ctx: RequestContext<...>, request: Request) {
  assert(ctx.conn !== undefined);
  assert(ctx.conn.id === expectedConnId);
  // Test other context methods...
  return new Response("ok");
}

🔒 Security Considerations

No security concerns identified. The changes maintain the same access control patterns as before.

⚡ Performance Considerations

Minor Overhead: Creating an additional context wrapper object on each request/WebSocket connection adds minimal overhead. Given that these are relatively infrequent operations (compared to action calls), this is negligible.

Optimization Note: The contexts delegate all calls to ActorContext, which in turn delegates to ActorInstance. This is an acceptable pattern, but be aware of the indirection chain for any future performance-sensitive paths.

📋 Breaking Changes

This is a breaking change for any code using onRequest or onWebSocket handlers:

Parameter signature changed from ActorContext to RequestContext/WebSocketContext
The opts parameter was removed from onRequest

Migration path is straightforward:

// Before
onRequest(ctx: ActorContext<...>, request: Request, opts: {}) {
  // No access to conn
}

// After
onRequest(ctx: RequestContext<...>, request: Request) {
  // Can now access ctx.conn
}

✅ Final Verdict

Approve with minor suggestions. The changes are well-structured and improve the API significantly. The main areas for consideration are:

Documentation fix for the JSDoc return type comment in config.ts:416
Consider addressing code duplication between context classes (not blocking)
Consider adding explicit tests for the new context types (not blocking)

The breaking changes are justified by the improved API, and the migration path is clear.

Overall: Strong improvement to the RivetKit API. Nice work! 🚀

pkg-pr-new · 2025-11-10T00:20:58Z

More templates

@rivetkit/actor

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/actor@3427

@rivetkit/cloudflare-workers

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/cloudflare-workers@3427

@rivetkit/core

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/core@3427

@rivetkit/db

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/db@3427

@rivetkit/framework-base

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/framework-base@3427

@rivetkit/next-js

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/next-js@3427

@rivetkit/react

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/react@3427

rivetkit

pnpm add https://pkg.pr.new/rivet-dev/rivet/rivetkit@3427

@rivetkit/sql-loader

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/sql-loader@3427

@rivetkit/engine-runner

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/engine-runner@3427

@rivetkit/engine-runner-protocol

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/engine-runner-protocol@3427

commit: 57377f5

claude · 2025-11-13T02:50:58Z

Code Review

This PR introduces specialized context types (RequestContext and WebSocketContext) for raw HTTP and WebSocket handlers, replacing the generic ActorContext. This is a well-designed improvement that provides better type safety and API clarity.

Positives

1. Strong API Design

The new context types follow the established pattern from ActionContext (rivetkit-typescript/packages/rivetkit/src/actor/contexts/action.ts:1-178), maintaining consistency across the codebase
Connection-specific contexts make the API more intuitive - developers can now access ctx.conn directly in raw handlers
Proper separation of concerns: actor-wide operations vs connection-specific operations are now clearly distinguished

2. Code Quality

Implementation is clean with proper private field encapsulation using #actorContext
Comprehensive JSDoc documentation on all public methods and the class itself
Type parameters are correctly threaded through (TState, TConnParams, TConnState, etc.)
Consistent delegation pattern to the underlying ActorContext

3. Excellent Documentation

Clear JSDoc comments explaining the purpose of each context type
Proper @typeParam documentation for all generic parameters
Updated config.ts with detailed @param documentation for the new handler signatures (rivetkit-typescript/packages/rivetkit/src/actor/config.ts:409-437)

4. Proper Export Management

New types correctly exported from rivetkit-typescript/packages/rivetkit/src/actor/mod.ts:79-80
Public API surface is well-defined

Suggestions

1. Missing Documentation on @param Tags
The class-level JSDoc is excellent, but the constructor documentation could be more explicit:

/**
 * Should not be called directly.
 *
 * @param actorContext - The actor context
 * @param conn - The connection associated with the request
 */
constructor(...)

Consider adding:

/**
 * Creates a new RequestContext. Should not be called directly by user code.
 * This is automatically created by the RivetKit runtime when handling raw HTTP requests.
 *
 * @internal
 * @param actorContext - The underlying actor context providing access to actor-level operations
 * @param conn - The connection associated with this specific HTTP request
 */
constructor(...)

The @internal tag would clarify this is not part of the public construction API.

2. Consider Readonly State Access
Currently, state and vars are exposed as mutable getters. While this matches the pattern in ActionContext and ActorContext, consider whether request/websocket handlers should be able to mutate state. If mutation is intentional, this is fine. If not, consider:

get state(): Readonly<TState> {
    return this.#actorContext.state;
}

This is a design question rather than a bug - just worth considering the intended behavior.

3. Type Safety Enhancement (Optional)
The broadcast method uses any[] for args:

broadcast(name: string, ...args: any[]): void

Consider using unknown[] for better type safety, matching the pattern in ActorContext (rivetkit-typescript/packages/rivetkit/src/actor/contexts/actor.ts:62):

broadcast(name: string, ...args: unknown[]): void

Security & Performance

No security concerns identified
No performance issues - the contexts are lightweight wrappers
Proper cleanup is handled in the router (rivetkit-typescript/packages/rivetkit/src/actor/router-endpoints.ts:392-407)

Test Coverage

The fixture updates in raw-http.ts and raw-http-request-properties.ts demonstrate the new context types work correctly. The changes are minimal and focused, which is good.

Consider adding explicit tests for:

Accessing ctx.conn in request handlers
Accessing ctx.conn in websocket handlers
Verifying connection lifecycle with the new context types

Overall Assessment

This is a high-quality PR that improves the API design without breaking changes beyond the context type. The implementation is consistent with existing patterns, well-documented, and type-safe. The suggestions above are minor improvements rather than blockers.

Recommendation: Approve with optional improvements

Great work on maintaining architectural consistency!

claude · 2025-11-13T03:01:14Z

Pull Request Review: Add `WebSocketContext` and `RequestContext`

Summary

This PR introduces specialized context classes (RequestContext and WebSocketContext) for raw HTTP and WebSocket handlers, improving type safety and API consistency by providing connection-specific context rather than the general ActorContext.

✅ Strengths

Excellent API Design: The new context classes follow the established pattern from ActionContext, maintaining consistency across the codebase.
Improved Type Safety: By using specialized contexts, the API now clearly distinguishes between different handler types, making it harder to misuse the API.
Better Encapsulation: The new contexts provide access to the specific Conn instance associated with the request/WebSocket, which is more appropriate than exposing the entire actor context.
Clean Implementation: Both context classes properly delegate to the underlying ActorContext using private fields, following the wrapper pattern established in ActionContext.
Consistent Documentation: The JSDoc comments are thorough and match the style of existing context classes.

🔍 Code Quality Observations

Minor Suggestions

Missing Type Helper Exports (Low Priority)

Consider adding type helpers similar to ActorContextOf and ActionContextOf in rivetkit-typescript/packages/rivetkit/src/actor/definition.ts:

export type RequestContextOf<AD extends AnyActorDefinition> =
  AD extends ActorDefinition<infer S, infer CP, infer CS, infer V, infer I, infer DB, any>
    ? RequestContext<S, CP, CS, V, I, DB>
    : never;

export type WebSocketContextOf<AD extends AnyActorDefinition> =
  AD extends ActorDefinition<infer S, infer CP, infer CS, infer V, infer I, infer DB, any>
    ? WebSocketContext<S, CP, CS, V, I, DB>
    : never;

These would provide a consistent pattern for extracting context types from actor definitions.

Documentation Enhancement (Very Low Priority)
- In config.ts:412-416, the updated JSDoc could mention what the conn property on the context provides:
```
/**
 * @param c The request context with access to the connection and actor state
 * @param request The raw HTTP request object
 */
```

🎯 Architecture & Patterns

Perfect Pattern Consistency: The implementation perfectly mirrors ActionContext, which is exactly right. All three context classes now share the same structure.
Proper Delegation: Both contexts correctly wrap ActorContext and expose conn, making the API intuitive.
Breaking Change Handled Well: The fixture updates show that the migration is straightforward - just changing ActorContext to the more specific context type.

🔒 Security Considerations

No security concerns identified. The contexts properly encapsulate the actor instance using private fields.

⚡ Performance Considerations

The additional context wrapper adds minimal overhead (one extra object allocation per request/WebSocket).
This is acceptable given the improved type safety and API clarity.

🧪 Test Coverage

The changes update existing driver test fixtures (raw-http.ts, raw-http-request-properties.ts), which will exercise the new context classes.
No additional test coverage appears necessary as the contexts are thin wrappers with straightforward delegation.

📝 Additional Notes

Import Organization: The fixture files correctly reorganize imports to use named imports (actor, type RequestContext), following TypeScript best practices.
Type Parameter Consistency: Both new context classes use the exact same 6 type parameters as ActionContext and ActorContext, maintaining consistency.
API Simplification: Removing the unused opts parameter from onRequest and making the signatures more consistent is a nice improvement.

✨ Verdict

Approved ✓

This is a well-executed refactoring that improves the API design without introducing any issues. The code follows established patterns, maintains consistency, and provides better type safety for users of the raw HTTP and WebSocket handlers. The only suggestions are minor enhancements that could be addressed in future PRs if desired.

Great work! 🎉

vercel · 2025-11-13T20:54:05Z

Deployment failed with the following error:

Too many requests - try again in 1 minute (more than 120, code: "api-deployments-flood-pro").

Learn More: https://vercel.com/docs/limits#rate-limits

claude · 2025-11-13T21:03:34Z

Pull Request Review

This PR introduces RequestContext and WebSocketContext as specialized context types for the onRequest and onWebSocket handlers. Overall, the changes are well-structured and improve the API by providing connection-specific context. Here's my detailed feedback:

Strengths

Good API Design: The new context classes provide a cleaner, more intuitive API by exposing the conn property directly on the context, making it clear which connection is associated with each request/WebSocket.
Code Reuse: Both RequestContext and WebSocketContext properly delegate to the underlying ActorContext, following the decorator/wrapper pattern effectively.
Documentation: The JSDoc comments are comprehensive and helpful, clearly explaining the purpose of each context type and its type parameters.
Fixture Updates: The test fixtures were correctly updated to use the new RequestContext type.
Breaking Change is Minimal: The signature change from ActorContext to RequestContext/WebSocketContext is a reasonable breaking change that improves clarity.

Issues Found

1. Code Duplication (Medium Priority)

Location: rivetkit-typescript/packages/rivetkit/src/actor/contexts/request.ts and rivetkit-typescript/packages/rivetkit/src/actor/contexts/websocket.ts

Both files are nearly identical (183 lines each, identical implementation). This violates DRY principles and creates maintenance burden.

Suggestion: Consider creating a base class or using a generic factory function:

// Option 1: Base class
abstract class ConnContext<TState, TConnParams, TConnState, TVars, TInput, TDatabase extends AnyDatabaseProvider> {
  #actorContext: ActorContext<...>;
  public readonly conn: Conn<...>;
  
  constructor(actorContext, conn) { ... }
  // All shared getters and methods
}

export class RequestContext<...> extends ConnContext<...> {}
export class WebSocketContext<...> extends ConnContext<...> {}

2. Inconsistent Parameter Removal (Low Priority)

Location: rivetkit-typescript/packages/rivetkit/src/actor/config.ts:409-423

The onRequest handler signature changed:

Before: onRequest(c, request, opts)
After: onRequest(c, request)

The empty opts: {} parameter was removed, but in onWebSocket the opts parameter was kept:

onWebSocket(c, websocket, opts)

Question: Is there a reason for this inconsistency? If opts will never be used for onRequest, removing it makes sense. However, if there's potential for future options, keeping it might provide better API stability.

3. Typo in Error Class (Low Priority)

Location: rivetkit-typescript/packages/rivetkit/src/actor/instance/mod.ts:657

throw new errors.RequestHandlerNotDfeined();
//                                    ^ Should be "Defined"

This typo exists in the current code and is not introduced by this PR, but it would be good to fix it while you're working in this area.

Observations

Connection Lifecycle: The changes properly maintain the connection lifecycle. Connections are created before the handlers are called and cleaned up in the finally blocks (lines 398-400 and 506-509 in router-endpoints.ts).
Type Safety: The type parameters are correctly threaded through all the new context classes, maintaining full type safety.
Export Additions: The new context types are properly exported in src/actor/mod.ts:79-80.

Test Coverage

The existing test suite appears comprehensive:

✅ Tests verify request properties are passed correctly
✅ Tests check state management across requests
✅ Tests validate different HTTP methods and content types
✅ Tests ensure concurrent requests maintain separate contexts

Suggestion: Consider adding a test that explicitly verifies the conn property is accessible and has the expected properties in the RequestContext and WebSocketContext. For example:

test("should provide connection in RequestContext", async (c) => {
  const actor = client.someActor.getOrCreate(["test"]);
  const response = await actor.fetch("test/conn");
  const data = await response.json();
  
  // Verify conn properties are accessible
  expect(data.hasConn).toBe(true);
  expect(data.connId).toBeTruthy();
});

Performance Considerations

No performance concerns. The wrapper contexts add minimal overhead (one additional object allocation per request/WebSocket).

Security Considerations

No security concerns identified. The contexts properly encapsulate the connection and delegate to the actor context without exposing internals.

Recommendations

High Priority: Consider refactoring to eliminate the code duplication between RequestContext and WebSocketContext.
Medium Priority: Clarify whether opts should be removed from onWebSocket for consistency, or added back to onRequest for future extensibility.
Low Priority: Fix the RequestHandlerNotDfeined typo.
Optional: Add explicit tests for the conn property accessibility.

Summary

This is a solid PR that improves the RivetKit API. The main concern is code duplication, which should be addressed before merging. The breaking change is justified by the improved API clarity.

Overall Assessment: Approve with recommendations for improvements.

claude · 2025-11-13T21:05:39Z

PR Review: Add `WebSocketContext` and `RequestContext`

Summary

This PR introduces two new specialized context types (RequestContext and WebSocketContext) to provide more precise typing for raw HTTP and WebSocket handlers in RivetKit. This is a good refactoring that improves type safety and API clarity.

✅ Strengths

Better Type Safety: The new context types make the API more explicit about what context is available in different handlers
Improved API Design: Separating RequestContext and WebSocketContext from ActorContext makes the API clearer and more intuitive
Clean Implementation: Both new context classes properly delegate to the underlying ActorContext while exposing conn directly
Good Documentation: JSDoc comments are comprehensive and follow existing patterns
Proper Exports: New types are correctly exported from the main module
Test Coverage: Existing test fixtures have been updated to use the new types

🔍 Code Quality Observations

Excellent:

Consistent implementation between RequestContext and WebSocketContext
Proper use of private fields (#actorContext) for encapsulation
All relevant ActorContext methods are properly exposed
Signature changes are minimal and focused

Good Pattern:

The delegation pattern is clean:

get state(): TState {
    return this.#actorContext.state;
}

🤔 Potential Issues & Suggestions

1. Missing Helper Types (Medium Priority)

The PR adds RequestContext and WebSocketContext but doesn't add corresponding helper types like RequestContextOf and WebSocketContextOf that exist for ActorContextOf and ActionContextOf in src/actor/definition.ts:21-48.

Recommendation: Add these helper types for consistency:

// In src/actor/definition.ts
export type RequestContextOf<AD extends AnyActorDefinition> =
    AD extends ActorDefinition<infer S, infer CP, infer CS, infer V, infer I, infer DB, any>
        ? RequestContext<S, CP, CS, V, I, DB>
        : never;

export type WebSocketContextOf<AD extends AnyActorDefinition> =
    AD extends ActorDefinition<infer S, infer CP, infer CS, infer V, infer I, infer DB, any>
        ? WebSocketContext<S, CP, CS, V, I, DB>
        : never;

Then export them from src/actor/mod.ts.

2. Documentation: Missing `@param` for `conn` (Low Priority)

In both context constructors, the conn parameter JSDoc says "Should not be called directly" but doesn't document the conn parameter itself. While it's a readonly public field, adding the param doc would be complete:

/**
 * Should not be called directly.
 *
 * @param actorContext - The actor context
 * @param conn - The connection associated with the request/WebSocket
 */

Current code already has this, so this is good. ✅

3. Breaking Change Considerations (Info)

The signature changes:

onRequest: removed opts: {} parameter (was unused)
onWebSocket: opts now only in third parameter (moved from being implicit)

These are minor breaking changes but seem reasonable given:

The opts: {} in onRequest was always empty
The changes improve the API design
Test fixtures show the migration is straightforward

Question for team: Should this be noted in a changelog/migration guide?

4. Code Duplication (Low Priority)

RequestContext and WebSocketContext are nearly identical (183 lines each). Consider:

Whether a shared base class would reduce duplication
If keeping them separate is intentional for future divergence

Current approach seems fine given:

They may diverge in the future
The duplication is minimal and maintainable
Type safety benefits outweigh DRY concerns here

🔒 Security

No security concerns identified. The changes are primarily type-level refactoring.

⚡ Performance

No performance concerns. The changes add a thin wrapper layer but:

Delegation is direct with no additional processing
No new allocations beyond the context object itself
Impact is negligible

🧪 Testing

Current Coverage:

✅ Test fixtures updated (raw-http.ts, raw-http-request-properties.ts)
✅ Existing tests in driver-test-suite/tests/ cover the functionality
✅ Both onRequest and onWebSocket handlers tested

Suggestions:

Consider adding explicit tests for the new context types' methods (accessing conn, state, etc.)
Verify that conn is properly scoped to the request/websocket

📋 Final Recommendations

Must Fix:

None (code is production-ready)

Should Consider:

Add RequestContextOf and WebSocketContextOf helper types for consistency with existing patterns
Document whether this is a breaking change and needs migration notes

Nice to Have:

Add explicit unit tests for the new context types
Consider if code duplication between contexts will become maintenance burden

✅ Overall Assessment

Code Quality: ⭐⭐⭐⭐⭐ Excellent
Type Safety: ⭐⭐⭐⭐⭐ Excellent
Documentation: ⭐⭐⭐⭐ Good
Testing: ⭐⭐⭐⭐ Good

Recommendation: APPROVE with minor suggestions

This is a solid refactoring that improves the API design and type safety. The implementation is clean and well-documented. The suggestions above are minor enhancements that would make the API even more consistent with existing patterns.

Great work on this improvement! 🎉

graphite-app · 2025-11-13T21:15:16Z

Merge activity

Nov 13, 9:15 PM UTC: NathanFlurry added this pull request to the Graphite merge queue.
Nov 13, 9:15 PM UTC: CI is running for this pull request on a draft pull request (#3465) due to your merge queue CI optimization settings.
Nov 13, 9:16 PM UTC: Merged by the Graphite merge queue via draft PR: #3465.

NathanFlurry mentioned this pull request Nov 10, 2025

chore(rivetkit): rename onstart/onstop to onwake/onsleep #3422

Closed

This was referenced Nov 10, 2025

chore(rivetkit): add connection for raw http #3425

Closed

chore(rivetkit): add conn type #3426

Closed

refactor(rivetkit): restructure connection lifecycle contexts #3428

Closed

vercel bot deployed to Preview – rivetkit-serverless November 10, 2025 00:20 View deployment

NathanFlurry mentioned this pull request Nov 13, 2025

wip: cf workers fix #3459

Closed

NathanFlurry force-pushed the 11-09-chore_rivetkit_add_websocketcontext_and_requestcontext_ branch from b1ac4de to 9878acc Compare November 13, 2025 02:47

NathanFlurry force-pushed the 11-09-chore_rivetkit_add_conn_type branch from 22fd1d2 to 7ac46b6 Compare November 13, 2025 02:47

vercel bot deployed to Preview – rivetkit-serverless November 13, 2025 02:48 View deployment

This was referenced Nov 13, 2025

chore(rivetkit-typescript): remove dependency on node modules #3460

Merged

chore(rivetkit): switch dynamic node imports to use require #3461

Merged

chore(rivetkit): fix type checks #3462

Merged

This was referenced Nov 13, 2025

feat(gas): implement smart pulling for horizontally scaled workers #3417

Merged

fix(guard): handle websocket tasks during shutdown #3448

Merged

fix: improve sigterm handling for the entire runtime #3443

Merged

NathanFlurry mentioned this pull request Nov 13, 2025

feat(gateway): websocket hibernation #3400

Merged

This was referenced Nov 13, 2025

fix(pb): dont immediately reallocate actors on runner stopping #3413

Merged

fix(guard): dont send open msg for hibernating ws, hibernating ws keepalive #3449

Merged

NathanFlurry mentioned this pull request Nov 13, 2025

chore(gas): rename wake sub to bump sub #3408

Merged

MasterPtato approved these changes Nov 13, 2025

View reviewed changes

chore(rivetkit): add WebSocketContext and RequestContext

57377f5

NathanFlurry force-pushed the 11-09-chore_rivetkit_add_websocketcontext_and_requestcontext_ branch from 9878acc to 57377f5 Compare November 13, 2025 20:53

NathanFlurry force-pushed the 11-09-chore_rivetkit_add_conn_type branch from 7ac46b6 to 1f30194 Compare November 13, 2025 20:54

NathanFlurry mentioned this pull request Nov 13, 2025

chore(rivetkit): implement new hibernating ws protocol #3464

Open

graphite-app bot pushed a commit that referenced this pull request Nov 13, 2025

chore(rivetkit): add WebSocketContext and RequestContext (#3427)

3becc58

graphite-app bot closed this Nov 13, 2025

graphite-app bot deleted the 11-09-chore_rivetkit_add_websocketcontext_and_requestcontext_ branch November 13, 2025 21:16

NathanFlurry mentioned this pull request Nov 13, 2025

feat(cloudflare-workers): add createInlineClient #3466

Open

NicholasKissel mentioned this pull request Nov 15, 2025

chre: v4 website changes #3472

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore(rivetkit): add `WebSocketContext` and `RequestContext` #3427

chore(rivetkit): add `WebSocketContext` and `RequestContext` #3427

Uh oh!

NathanFlurry commented Nov 10, 2025

Uh oh!

vercel bot commented Nov 10, 2025 •

edited

Loading

Uh oh!

NathanFlurry commented Nov 10, 2025 •

edited

Loading

Uh oh!

claude bot commented Nov 10, 2025

Uh oh!

pkg-pr-new bot commented Nov 10, 2025 •

edited

Loading

Uh oh!

claude bot commented Nov 13, 2025

Uh oh!

claude bot commented Nov 13, 2025

Uh oh!

vercel bot commented Nov 13, 2025

Uh oh!

claude bot commented Nov 13, 2025

Uh oh!

claude bot commented Nov 13, 2025

Uh oh!

graphite-app bot commented Nov 13, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

chore(rivetkit): add WebSocketContext and RequestContext #3427

chore(rivetkit): add WebSocketContext and RequestContext #3427

Uh oh!

Conversation

NathanFlurry commented Nov 10, 2025

Uh oh!

vercel bot commented Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NathanFlurry commented Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

How to use the Graphite Merge Queue

Uh oh!

claude bot commented Nov 10, 2025

PR Review: Add WebSocketContext and RequestContext

Overview

✅ Positives

🔍 Code Quality Observations

🤔 Suggestions & Considerations

1. Code Duplication Between Context Classes

2. Missing Return Value in config.ts

3. Removed opts Parameter

4. Missing Tests for New Context Classes

🔒 Security Considerations

⚡ Performance Considerations

📋 Breaking Changes

✅ Final Verdict

Uh oh!

pkg-pr-new bot commented Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

claude bot commented Nov 13, 2025

Code Review

Positives

Suggestions

Security & Performance

Test Coverage

Overall Assessment

Uh oh!

claude bot commented Nov 13, 2025

Pull Request Review: Add WebSocketContext and RequestContext

Summary

✅ Strengths

🔍 Code Quality Observations

Minor Suggestions

🎯 Architecture & Patterns

🔒 Security Considerations

⚡ Performance Considerations

🧪 Test Coverage

📝 Additional Notes

✨ Verdict

Uh oh!

vercel bot commented Nov 13, 2025

Uh oh!

claude bot commented Nov 13, 2025

Pull Request Review

Strengths

Issues Found

1. Code Duplication (Medium Priority)

2. Inconsistent Parameter Removal (Low Priority)

3. Typo in Error Class (Low Priority)

Observations

Test Coverage

Performance Considerations

Security Considerations

Recommendations

Summary

Uh oh!

claude bot commented Nov 13, 2025

PR Review: Add WebSocketContext and RequestContext

Summary

✅ Strengths

🔍 Code Quality Observations

Excellent:

Good Pattern:

🤔 Potential Issues & Suggestions

1. Missing Helper Types (Medium Priority)

2. Documentation: Missing @param for conn (Low Priority)

3. Breaking Change Considerations (Info)

4. Code Duplication (Low Priority)

chore(rivetkit): add `WebSocketContext` and `RequestContext` #3427

chore(rivetkit): add `WebSocketContext` and `RequestContext` #3427

vercel bot commented Nov 10, 2025 •

edited

Loading

NathanFlurry commented Nov 10, 2025 •

edited

Loading

PR Review: Add `WebSocketContext` and `RequestContext`

2. Missing Return Value in `config.ts`

3. Removed `opts` Parameter

pkg-pr-new bot commented Nov 10, 2025 •

edited

Loading

Pull Request Review: Add `WebSocketContext` and `RequestContext`

PR Review: Add `WebSocketContext` and `RequestContext`

2. Documentation: Missing `@param` for `conn` (Low Priority)

graphite-app bot commented Nov 13, 2025 •

edited

Loading