Skip to content

fix(rivetkit): make duplicate sleep requests idempotent#4934

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

fix(rivetkit): make duplicate sleep requests idempotent#4934
NathanFlurry merged 1 commit intomainfrom
05-04-fix_rivetkit_sleep_idempotent_request

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 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: fix(rivetkit): make duplicate sleep requests idempotent

Overview

This PR makes duplicate ctx.sleep() calls idempotent by returning Ok(()) instead of Err(ActorLifecycleError::Stopping) when sleep_requested was already set. It also re-enables a previously skipped test and improves its design to avoid the race conditions inherent in the original test structure.


Core Rust Change

Correct and minimal. The sleep_requested.swap(true, Ordering::SeqCst) returning true correctly signals a duplicate call. Returning Ok(()) here is semantically sound -- the actor will sleep as requested, the second call is just redundant.

Asymmetry with destroy() warrants a note. destroy() still returns Err(ActorLifecycleError::Stopping) on duplicate calls (lines 447-448 of context.rs). This asymmetry may be intentional (destroy is a stronger, escalating signal and is explicitly allowed after sleep), but it is worth confirming and documenting. The CLAUDE.md invariant in rivetkit-rust/packages/rivetkit-core/CLAUDE.md now needs updating -- the current bullet reads:

ctx.sleep() and ctx.destroy() return Result<()>. They error with ActorLifecycleError::Starting when called before startup completes and ActorLifecycleError::Stopping if the requested flag has already been set this generation.

After this change, sleep() no longer errors on duplicate -- only destroy() does. The bullet should be split to reflect the different behaviors.


Test Change

The test redesign is the right call. The original skipped test called triggerSleep twice sequentially via a connection, which had an inherent race: the second action could arrive after the actor had already started its shutdown sequence, requiring a try/catch workaround. The new triggerSleepTwice action calls sleep() twice within a single synchronous action invocation, directly testing the idempotency path in core without timing sensitivity.

Comments are clear and accurate. The new inline comment correctly explains why triggerSleepTwice is used over two separate calls.

Test assertions look correct. Expecting sleepCount === 1 and startCount === 2 after one double-sleep cycle correctly verifies that only one sleep occurred and the actor woke back up exactly once.


Minor Notes

  • triggerSleepTwice is defined consistently across all three actor variants in sleep-db.ts (lines 49, 200, 277).
  • Neither c.sleep() call has its return value checked in the fixture -- this is fine since the TypeScript c.sleep() is synchronous/void and after this fix neither call will throw for a started actor.
  • No new test covers calling sleep() after the actor has already begun the grace period (lifecycle_started == false but sleep_requested == true). That path still correctly returns Err("actor is already shutting down"), but coverage for that boundary would be a nice follow-up.

Summary

The change is correct, well-scoped, and the test redesign is a meaningful improvement over the original flaky structure. One actionable item before merge:

  1. Update the sleep invariant bullet in rivetkit-rust/packages/rivetkit-core/CLAUDE.md to reflect that sleep() is now idempotent on duplicate calls, while destroy() still errors.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 4, 2026

Preview packages published to npm

Install with:

npm install rivetkit@pr-4934

All packages published as 0.0.0-pr.4934.a2001b4 with tag pr-4934.

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

@NathanFlurry NathanFlurry force-pushed the graphite-base/4934 branch from 76cce67 to b81dab2 Compare May 4, 2026 09:10
@NathanFlurry NathanFlurry force-pushed the 05-04-fix_rivetkit_sleep_idempotent_request branch from ea54634 to ae09be0 Compare May 4, 2026 09:10
@NathanFlurry NathanFlurry changed the base branch from graphite-base/4934 to main May 4, 2026 09:10
@NathanFlurry NathanFlurry merged commit ae09be0 into main May 5, 2026
39 of 54 checks passed
@NathanFlurry NathanFlurry deleted the 05-04-fix_rivetkit_sleep_idempotent_request 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