Skip to content

Conversation

@NathanFlurry
Copy link
Member

No description provided.

@vercel
Copy link

vercel bot commented Nov 3, 2025

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

Project Deployment Preview Comments Updated (UTC)
rivetkit-serverless Ready Ready Preview Comment Nov 4, 2025 7:00pm
3 Skipped Deployments
Project Deployment Preview Comments Updated (UTC)
rivet-cloud Ignored Ignored Nov 4, 2025 7:00pm
rivet-inspector Ignored Ignored Preview Nov 4, 2025 7:00pm
rivet-site Ignored Ignored Preview Nov 4, 2025 7:00pm

Copy link
Member Author

NathanFlurry commented Nov 3, 2025

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
Copy link

claude bot commented Nov 3, 2025

PR Review: chore(rivetkit): document sleep sequence better

Summary: This PR improves clarity of the actor sleep/stop lifecycle by renaming _sleep() to _startSleep() and _stop() to _onStop(), plus adding comprehensive documentation.

Code Quality - Positive Changes:

  1. Better naming conventions make purpose clearer
  2. Improved documentation explains the sleep sequence flow
  3. Clearer state management with sleepCalled set before driver calls
  4. Important fix: duplicate call check moved before setting sleepCalled

Concerns:

  1. Stale comment references - Comments at lines 6 (actor-sleep.ts), 1960/1988/1992 (instance.ts), and 41 (actor/driver.ts) still reference old method names
  2. Behavior change in isStopping - Now only checks stopCalled, not sleepCalled. Should be documented in PR description
  3. Removed safety check from assertReady - Operations can proceed after sleep initiated but before onStop called. Verify no race conditions

Testing: Existing test suite is comprehensive. Consider adding test for window between _startSleep() and _onStop() execution.

Recommendations:

  1. Update stale comments to reference new method names
  2. Document behavioral change in PR description
  3. Add edge case tests for sleep start/stop window
  4. Verify no race conditions with removed sleepCalled check

Overall: Good refactoring that improves clarity and maintainability. Main issue is outdated comments. Once addressed, ready to merge.

@NathanFlurry NathanFlurry force-pushed the 11-03-chore_rivetkit_document_sleep_sequence_better branch from c919694 to 2d6a1e2 Compare November 4, 2025 00:36
@NathanFlurry NathanFlurry force-pushed the 11-03-fix_runner_close_active_requests_after_onactorstop_has_finished_running branch from 30b896a to 09512fc Compare November 4, 2025 00:36
@claude
Copy link

claude bot commented Nov 4, 2025

Code Review

This PR improves documentation and clarifies the actor sleep/stop lifecycle. The changes are well-structured and improve code maintainability.

Strengths

  1. Improved Naming Clarity: Renaming _sleep() to _startSleep() and _stop() to _onStop() makes the intent much clearer - _startSleep() indicates this initiates the sleep sequence (not the entire process), and _onStop() clearly indicates this is a callback/handler rather than a direct stop method

  2. Excellent Documentation: The new JSDoc comments provide a clear sequence diagram of the sleep lifecycle with 4 clear steps documented inline

  3. Corrected State Management: Removing #sleepCalled from isStopping getter is a critical fix - this correctly reflects that the actor isn't actually stopping until _onStop is called

  4. Removed Premature Checks: Eliminating the #sleepCalled check from #assertReady() is correct - as the comment notes, sleep intent should not affect actor behavior until the actual stop sequence begins

Observations

  1. Typo in Documentation (instance.ts:1966, 2002): ActorStateSTop should be ActorStateStop (lowercase 'o')

  2. Comment Consistency (instance.ts:1992): The comment says "This will call _stop once Pegboard responds" but the method is now _onStop - should update to: "This will call _onStop once Pegboard responds"

  3. Driver Interface Comment (actor/driver.ts:41): Still references _stop: "This will call _stop independently" - should update to: "This will call _onStop independently"

Suggestions

  1. Fix typos mentioned above - these are minor but will help with searchability and professionalism
  2. Consider adding a sequence diagram to CLAUDE.md or docs - The sleep lifecycle is complex enough that a visual diagram in documentation would be helpful for future contributors

Security & Performance

  • No security concerns
  • No performance regressions (purely refactoring/documentation)
  • State management logic is more correct with the removal of #sleepCalled from stopping checks

Testing

  • The changes are primarily documentation and method renames
  • Existing tests should continue to pass
  • Sleep functionality is already tested in driver-memory.test.ts and driver-file-system.test.ts (though currently skipped for memory driver)

Summary

This is a solid refactoring PR that improves code clarity without changing behavior (except for the important bug fix in state management). The new naming convention and documentation make the sleep lifecycle much easier to understand. Just fix the three minor typos and this will be excellent.

Recommendation: Approve with minor documentation fixes

@claude
Copy link

claude bot commented Nov 4, 2025

PR Review: chore(rivetkit): document sleep sequence better

Summary

This PR improves documentation and naming clarity around the actor sleep/stop lifecycle. The changes make the sleep sequence easier to understand and fix a subtle bug where #sleepCalled was affecting actor behavior prematurely.


Positive Aspects

Excellent documentation improvements: The new JSDoc comments in _startSleep() and _onStop() clearly document the sleep sequence for the engine driver, making the control flow much easier to understand.

Better naming: Renaming _sleep()_startSleep() and _stop()_onStop() more accurately reflects what these methods do:

  • _startSleep() initiates the sleep intent but doesn't actually stop the actor
  • _onStop() is a callback invoked when the actor should stop

Critical bug fix: Removing #sleepCalled from the isStopping getter and #assertReady() is correct. As the new comment states: "#sleepCalled should have no effect on the actor's behavior aside from preventing calling _startSleep twice." Previously, calling _startSleep() would immediately make the actor appear to be "stopping" even though it was still fully operational.

Logical code flow: Moving the #sleepCalled check to the beginning of _startSleep() (before the invariant calls) is cleaner - it's a no-op if already sleeping, so checking early avoids unnecessary assertions.

Comprehensive test coverage: The existing test suite (actor-sleep.ts) has excellent coverage with 13 tests covering various sleep scenarios.


Observations & Suggestions

1. Typo in documentation (line 1966)

4. Engine runner will publish EventActorStateUpdate with ActorStateSTop

Should be ActorStateStop (lowercase 'p'). Same typo appears in line 2002.

2. Typo in old comment (line 6 of test file)
The test file comment references _sleep which should now be _startSleep for consistency:

// TODO: These tests are broken with fake timers because `_sleep` requires

3. Consider clarifying the state transition
The new comments excellently document the engine flow, but it might be helpful to add a note about what happens between steps 1 and 2. Specifically:

  • After publishing ActorIntentSleep, who sends CommandStopActor?
  • Is there engine orchestration happening in between?

This would help future maintainers understand the full distributed flow.

4. Potential race condition to verify
The code uses setImmediate() to defer the actual sleep call:

setImmediate(() => {
    sleep();
});

The comment says "This allows for any action that calls _sleep to complete." Can you confirm this handles the case where:

  • An RPC handler calls _startSleep()
  • The handler is still executing (has more code after the sleep() call)
  • The setImmediate callback fires

Does setImmediate guarantee the current synchronous execution completes first? Or should this be a full async cycle (e.g., Promise.resolve().then(...))?

5. Comment consistency in file-system driver
The file-system actor driver's startSleep() method has a minimal comment. Consider adding similar documentation there for consistency:

startSleep(actorId: string): void {
    // Spawns the sleepActor promise
    this.#state.sleepActor(actorId);
}

Security & Performance

✅ No security concerns identified
✅ No performance regressions - changes are primarily documentation and naming
✅ The bug fix actually improves correctness by not prematurely blocking operations


Verdict

Approved with minor suggestions. This is a high-quality refactoring that improves code clarity and fixes a subtle behavioral issue. The suggestions above are minor and non-blocking.

The core changes - especially fixing the isStopping behavior and adding comprehensive documentation - are excellent improvements to the codebase.


Generated with Claude Code

@claude
Copy link

claude bot commented Nov 4, 2025

Code Review

Summary

This PR improves documentation and clarity around the actor sleep sequence by:

  • Renaming _sleep() to _startSleep() to better indicate it initiates the sleep process
  • Renaming _stop() to _onStop() to clarify it's a callback handler
  • Adding detailed documentation comments explaining the sleep lifecycle
  • Refactoring the isStopping getter to only check #stopCalled
  • Removing premature sleep state checks from #assertReady()

Positive Aspects ✅

  1. Improved Naming Clarity: The rename from _sleep() to _startSleep() more accurately conveys that this method initiates the sleep sequence rather than directly sleeping the actor.

  2. Excellent Documentation: The added JSDoc comments clearly document the sleep sequence flow with actor intent publication, engine runner waiting for stop command, calling _onStop and waiting for completion, and publishing state update.

  3. Better Lifecycle Management: Moving the #sleepCalled check to the top of _startSleep() with a clear comment explaining that it should NOT affect actor behavior aside from preventing duplicate calls is a good architectural decision.

  4. Consistent with Callback Pattern: Renaming _stop() to _onStop() better indicates this is a lifecycle callback rather than a direct action.

  5. Comprehensive Test Coverage: The codebase has excellent test coverage for the sleep functionality at src/driver-test-suite/tests/actor-sleep.ts with 13 different test cases.

Concerns & Recommendations ⚠️

1. Timing Sensitivity in isStopping Change (Medium)

The change to isStopping removes the #sleepCalled check. There's now a window between when _startSleep() is called and when _onStop() is called where the actor thinks it's not stopping, but sleep has been initiated.

Impact: Any code that checks isStopping during this window might incorrectly assume the actor is not in a stopping state. This could lead to new operations being accepted that shouldn't be or race conditions.

Recommendation: Review all usages of isStopping to ensure they handle this correctly. Consider adding a isSleeping property if code needs to distinguish between these states.

2. #assertReady Behavioral Change (Medium)

The removal of the sleep check from #assertReady means operations that previously would have been rejected after _startSleep() was called will now succeed until _onStop() is called.

Questions: Is this intentional? Should operations be allowed during the sleep initiation phase? Could this cause issues with operations starting but not completing before _onStop() is called?

Recommendation: Add a comment explaining why operations are allowed during sleep initiation.

3. Documentation Updates Needed (Low)

  • Line 6 in actor-sleep.ts: Update TODO comment to reference _startSleep instead of _sleep
  • Line 1966: Typo "ActorStateSTop" should be "ActorStateStop"
  • Line 1992: Update comment to reference _onStop instead of _stop

Overall Assessment

This is a good refactoring that improves code clarity and documentation. The main concerns are around the behavioral changes to isStopping and #assertReady during the sleep initiation phase. These changes appear intentional based on the comment added, but should be validated to ensure no race conditions are introduced.

Recommendation: Approve with minor fixes for the typos and comment updates, but verify that the timing changes don't introduce issues in production scenarios.

@NathanFlurry NathanFlurry force-pushed the 11-03-fix_runner_close_active_requests_after_onactorstop_has_finished_running branch from 77aaf9c to 6655e70 Compare November 4, 2025 19:24
@NathanFlurry NathanFlurry force-pushed the 11-03-chore_rivetkit_document_sleep_sequence_better branch from 91b3d4f to 33295d8 Compare November 4, 2025 19:24
@vercel
Copy link

vercel bot commented Nov 4, 2025

Deployment failed with the following error:

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

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

@claude
Copy link

claude bot commented Nov 4, 2025

PR Review: Document sleep sequence better

Summary

This PR improves the documentation and naming clarity around the actor sleep lifecycle. The changes rename methods and add detailed documentation about the sleep sequence, particularly for the engine driver implementation.

Code Quality and Best Practices ✅

Strengths:

  • Clear naming improvement: Renaming _sleep() to _startSleep() better communicates that this method initiates the sleep sequence rather than completing it
  • Renaming _stop() to _onStop(): Makes it clear this is a callback/lifecycle hook rather than a public method to call directly
  • Excellent documentation: The added JSDoc comments clearly document the sleep sequence flow with numbered steps
  • Consistent updates: All call sites were updated correctly (context.ts, actor-driver.ts, global-state.ts)

Improvements made:

  1. Removed confusing state checks in #assertReady() that checked #sleepCalled
  2. Clarified that #sleepCalled should only prevent duplicate sleep calls, not affect actor behavior
  3. Better separation of concerns between starting sleep and stopping the actor

Potential Issues 🟡

1. isStopping property behavior change

// Before:
get isStopping() {
    return this.#stopCalled || this.#sleepCalled;
}

// After:
get isStopping() {
    return this.#stopCalled;
}

Impact: This is a behavioral change. Previously, isStopping would return true as soon as sleep was initiated. Now it only returns true after _onStop() is called.

Analysis: This appears intentional based on the comment "Wait for _onStop before putting in a stopping state." However, this could affect:

  • External code checking actor.isStopping
  • Any logic that depends on detecting actors that are about to stop

Recommendation: Consider:

  1. Adding a deprecation notice if this is a breaking change
  2. Adding a new isSleeping property if callers need to distinguish between sleep-initiated and actually-stopping states
  3. Documenting this behavior change in CHANGELOG if this is a public API

2. Removed #assertReady() checks
The removal of the #sleepCalled check from #assertReady() means operations can now proceed even after sleep is initiated (but before _onStop is called).

// Before: Would throw if sleeping
#assertReady(allowStoppingState: boolean = false) {
    if (\!this.#ready) throw new errors.InternalError("Actor not ready");
    if (\!allowStoppingState && this.#sleepCalled)
        throw new errors.InternalError("Actor is going to sleep");
    if (\!allowStoppingState && this.#stopCalled)
        throw new errors.InternalError("Actor is stopping");
}

// After: Only checks stopCalled
#assertReady(allowStoppingState: boolean = false) {
    if (\!this.#ready) throw new errors.InternalError("Actor not ready");
    if (\!allowStoppingState && this.#stopCalled)
        throw new errors.InternalError("Actor is stopping");
}

Analysis: This is consistent with the intent stated in the comments - sleep initiation shouldn't affect actor behavior. However:

Methods affected:

  • handleConnection() (line 990)
  • handleFetch() (line 1516)
  • handleWebSocket() (line 1550)
  • Other methods calling #assertReady()

These can now accept new connections/requests/websockets after _startSleep() is called but before _onStop() completes.

Recommendation:

  • Verify this is the intended behavior
  • Ensure the engine properly handles the race condition where:
    1. Actor calls _startSleep()
    2. Engine receives ActorIntentSleep
    3. Before engine sends CommandStopActor, a new request arrives
    4. Actor accepts the request
    5. Engine stops the actor mid-request

Performance Considerations ✅

No performance concerns. The changes are primarily documentation and naming improvements.

Security Concerns ✅

No security issues identified. The changes maintain the same security posture.

Test Coverage 🟢

Existing test coverage is comprehensive:

  • actor-sleep.ts contains 13 test cases covering:
    • Basic sleep and state persistence
    • Sleep with connections
    • Automatic sleep after timeout
    • RPC calls keeping actors awake
    • Alarms keeping actors awake and waking actors
    • Long-running RPCs
    • Raw WebSockets keeping actors awake
    • Raw fetch requests keeping actors awake
    • noSleep option

Tests should validate the behavioral changes:
The existing tests should catch issues with the isStopping and #assertReady changes, but consider adding specific tests for:

  1. Verifying isStopping returns false after _startSleep() but before _onStop()
  2. Verifying requests can be accepted after _startSleep() but before _onStop()
  3. Race condition handling between sleep initiation and new requests

Additional Observations

Typo in documentation:
Line 1966 has a typo: ActorStateSTop should be ActorStateStop
Line 2002 has the same typo: ActorStateSTop should be ActorStateStop

Comment consistency:
Line 1992: Comment says "This will call _stop once Pegboard responds" but should say "This will call _onStop once Pegboard responds"

Recommendations

  1. Fix typos in the JSDoc comments (ActorStateSTopActorStateStop, _stop_onStop)
  2. Consider adding isSleeping property if callers need to distinguish sleep-initiated state
  3. Verify race condition handling between _startSleep() and new incoming requests
  4. Document the behavior change if isStopping is part of the public API
  5. Run the sleep test suite to ensure the behavioral changes don't break existing tests

Overall Assessment

This is a solid refactoring that improves code clarity and documentation. The main concerns are around the behavioral changes to isStopping and #assertReady(), which should be intentional but need verification that they don't introduce race conditions or break existing assumptions.

Recommendation: Approve with minor fixes for typos and verification of the behavioral changes.


Review generated by Claude Code

@claude
Copy link

claude bot commented Nov 4, 2025

PR Review: chore(rivetkit): document sleep sequence better

Summary

This PR improves clarity around the actor sleep/stop sequence by:

  • Renaming _sleep() to _startSleep() to better reflect its initiating role
  • Renaming _stop() to _onStop() to clarify it's a callback invoked by the driver
  • Removing premature stopping state checks during sleep initialization
  • Adding comprehensive documentation about the sleep/stop sequence flow

Code Quality - Approved

Strengths:

  • Excellent naming improvements: The new names are much more descriptive and accurately reflect their roles in the actor lifecycle
  • Well-documented flow: The added JSDoc comments clearly explain the 4-step engine sleep sequence
  • Consistent application: All references across drivers are updated consistently

Potential Issues

1. Outdated comment in test file (Minor)
Location: rivetkit-typescript/packages/rivetkit/src/driver-test-suite/tests/actor-sleep.ts:6

The TODO comment still references the old _sleep method name and should be updated to _startSleep for consistency.

2. Behavior change in isStopping getter (Needs verification)
Location: rivetkit-typescript/packages/rivetkit/src/actor/instance.ts:152-154

The isStopping getter no longer includes sleepCalled check. This is a semantic change - previously an actor entering sleep was considered stopping, but now it's only considered stopping after _onStop is called. This aligns with the documented intent, but ensure all callers of isStopping are aware of this behavior change.

3. Removed sleep assertion in assertReady (Needs verification)
Location: rivetkit-typescript/packages/rivetkit/src/actor/instance.ts:1295-1298

The sleepCalled check was removed from assertReady, meaning actors can now process operations after _startSleep is called but before _onStop executes. This appears intentional per the comments, but verify this doesn't allow unexpected operations during sleep transition.

Performance Considerations

No performance impact - purely refactoring and documentation improvements.

Security Concerns

No security concerns identified.

Test Coverage

Comprehensive test coverage exists in actor-sleep.ts with 13 test cases. Ensure tests still pass with these internal changes.

Recommendations

  1. Update the outdated comment in the test file
  2. Document the behavior change in isStopping if it affects public-facing behavior
  3. Run the existing test suite to verify behavioral changes
  4. Consider adding a comment near the isStopping getter explaining when it returns true

Overall Assessment: Approved with minor suggestions

This is a clean refactoring that significantly improves code clarity. The naming changes make the actor lifecycle much easier to understand. Great work on improving the codebase maintainability!

@graphite-app
Copy link
Contributor

graphite-app bot commented Nov 4, 2025

Merge activity

  • Nov 4, 8:09 PM UTC: NathanFlurry added this pull request to the Graphite merge queue.
  • Nov 4, 8:11 PM UTC: CI is running for this pull request on a draft pull request (#3349) due to your merge queue CI optimization settings.
  • Nov 4, 8:41 PM UTC: The Graphite merge queue removed this pull request due to removal of a downstack PR #3342.
  • Nov 4, 8:52 PM UTC: NathanFlurry added this pull request to the Graphite merge queue.
  • Nov 4, 8:53 PM UTC: CI is running for this pull request on a draft pull request (#3353) due to your merge queue CI optimization settings.
  • Nov 4, 8:56 PM UTC: Merged by the Graphite merge queue via draft PR: #3353.

@NathanFlurry NathanFlurry force-pushed the 11-03-fix_runner_close_active_requests_after_onactorstop_has_finished_running branch from 6655e70 to 856a3ff Compare November 4, 2025 20:25
@NathanFlurry NathanFlurry force-pushed the 11-03-chore_rivetkit_document_sleep_sequence_better branch from 33295d8 to 0e800d6 Compare November 4, 2025 20:25
@vercel
Copy link

vercel bot commented Nov 4, 2025

Deployment failed with the following error:

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

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

@claude
Copy link

claude bot commented Nov 4, 2025

PR Review: Document Sleep Sequence Better

Overview

This PR improves the clarity of the actor sleep lifecycle by renaming internal methods and adding comprehensive documentation. The changes help distinguish between the intent to sleep (_startSleep) and the actual stopping of the actor (_onStop).


✅ Positives

1. Clear Naming Convention

  • Renaming _sleep()_startSleep() clearly indicates this method initiates the sleep sequence rather than completing it
  • Renaming _stop()_onStop() better reflects that this is a lifecycle callback triggered by the engine
  • The naming now aligns with the documented flow: start sleep → wait for engine → handle stop

2. Excellent Documentation
The added JSDoc comments provide a clear step-by-step flow:

// For _startSleep:
1. Publish EventActorIntent with ActorIntentSleep (via driver.startSleep)
2. Engine runner will wait for CommandStopActor
3. Engine runner will call _onStop and wait for it to finish
4. Engine runner will publish EventActorStateUpdate with ActorStateSTop

3. Improved State Management Logic

  • Moving the #sleepCalled check to the beginning of _startSleep() is more logical
  • The comment clarifying that #sleepCalled should only prevent duplicate calls (not affect actor behavior) is excellent
  • Removing #sleepCalled checks from #assertReady() is correct - the actor shouldn't be in a "stopping" state until _onStop is called

4. Better Separation of Concerns

  • The removal of || this.#sleepCalled from the isStopping getter is correct - an actor that has started the sleep sequence isn't truly "stopping" until the engine calls _onStop

🔍 Issues & Suggestions

1. Outdated Comment (Minor)
Line 1988 and 1992 still reference the old method names:

// Schedule sleep to happen on the next tick. This allows for any action that calls _sleep to complete.
// ...
// This will call _stop once Pegboard responds with the new status

Suggestion: Update these to reference _startSleep and _onStop respectively:

// Schedule sleep to happen on the next tick. This allows for any action that calls _startSleep to complete.
// ...
// This will call _onStop once Pegboard responds with the new status

2. Typo in Documentation (Trivial)
Line 1966: ActorStateSTop should be ActorStateStop (capital T instead of lowercase)
Line 2002: Same typo ActorStateSTopActorStateStop

3. Test Comments Reference Old Behavior (Documentation Only)
The test file at src/driver-test-suite/tests/actor-sleep.ts:6-8 has a TODO comment that references _sleep:

// TODO: These tests are broken with fake timers because `_sleep` requires
// background async promises that have a race condition with calling
// `getCounts`

While this doesn't affect functionality, it would be good to update this to _startSleep for consistency.


🛡️ Security & Performance

No concerns. This is a refactoring/documentation change with no security or performance implications.


✅ Test Coverage

The PR maintains comprehensive test coverage:

  • All sleep-related tests pass with the renamed methods
  • Tests cover: manual sleep triggers, automatic timeout, RPC keeping actors awake, alarms, long-running operations, raw WebSockets, raw HTTP requests, and the noSleep option
  • The refactoring correctly updates all call sites in both the engine driver and file-system driver

📋 Summary

This is a high-quality refactoring PR that significantly improves code clarity and maintainability. The changes make the actor sleep lifecycle much easier to understand for developers working with this codebase.

Recommendation:Approve with minor suggestions

The issues identified are all trivial (typos and outdated comments) and don't block merging. They can be fixed now or in a follow-up.


🔧 Suggested Fixes

// rivetkit-typescript/packages/rivetkit/src/actor/instance.ts:1966
- * 4. Engine runner will publish EventActorStateUpdate with ActorStateSTop
+ * 4. Engine runner will publish EventActorStateUpdate with ActorStateStop

// rivetkit-typescript/packages/rivetkit/src/actor/instance.ts:1988
- // Schedule sleep to happen on the next tick. This allows for any action that calls _sleep to complete.
+ // Schedule sleep to happen on the next tick. This allows for any action that calls _startSleep to complete.

// rivetkit-typescript/packages/rivetkit/src/actor/instance.ts:1992
- // This will call _stop once Pegboard responds with the new status
+ // This will call _onStop once Pegboard responds with the new status

// rivetkit-typescript/packages/rivetkit/src/actor/instance.ts:2002
- * 3. Engine runner publishes EventActorStateUpdate with ActorStateSTop
+ * 3. Engine runner publishes EventActorStateUpdate with ActorStateStop

@graphite-app graphite-app bot changed the base branch from 11-03-fix_runner_close_active_requests_after_onactorstop_has_finished_running to graphite-base/3324 November 4, 2025 20:52
@graphite-app graphite-app bot closed this Nov 4, 2025
@graphite-app graphite-app bot deleted the 11-03-chore_rivetkit_document_sleep_sequence_better branch November 4, 2025 20:56
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.

3 participants