fix(rivetkit): isolate workflow run state per actor generation

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

Current stack:

• #5843 fix(envoy-client): keep the ping silence deadline bounded ac …
• #5838 fix(envoy-client): ignore pings from earlier connections in …
• #5823 fix(envoy-client): declare actors lost before the engine can …
• #5824 fix(rivetkit): stop lost actor generations immediately
• #5821 fix(envoy-client): signal lost actor generations synchronous …
• #5822 fix(rivetkit): isolate workflow run state per actor generati … 👈
• #5825 fix(rivetkit-napi): key actor runtime state by generation

Dependencies:

• #5816 chore(release): update version to 2.3.23
• main

Get stack: forklift get 5822
Push local edits: forklift submit
Merge when ready: forklift merge 5822

_{change wurkyvuq}

[claude]

Review: isolate workflow run state per actor generation

The approach looks sound. Keying the coordinator state and the workflow inspector registrations by (actorId, generation) fixes the stale-generation rebind problem. The core generation() accessor is exposed through NAPI, wasm and the CoreRuntime interface consistently, and NativeWorkflowRuntimeAdapter.generation matches what workflow/mod.ts reads from the actor internal. I did not run the tests.

Suggestions

1. Undefined to defined generation is not a replacement. In #getOrCreate, state created with an undefined generation is never replaced when a defined generation arrives (and the reverse). That is probably fine because the runtime either always or never reports a generation. A short comment saying so would help, since FakeActorContext in runtime-parity.test.ts returns null, which exercises only the legacy path.
2. Inspector key collision risk is low but real. The actorId#generation key could collide with an actor id that contains #. Actor ids are engine-generated so this is unlikely. A nested map would remove the question.
3. Test coverage. The coordinator tests cover supersession, late destroy and the stuck older run well. There is no test through the workflow() inspector dispose path, which should leave the newer generation registration intact. A small test would lock in the stale-disposer behavior.
4. Typing parity. NAPI returns number | null and wasm returns number | undefined. Both are handled by ?? undefined, so this is fine.

No security or performance concerns. Nit: the PR body is empty, so a short bullet summary would help.

[the-company-company]

✅ No issues found

_{Reviewed commit d389d55.}

[claude]

Review: isolate workflow run state per actor generation

Overall this is a focused, well-tested fix. generation() is plumbed through core, NAPI, wasm and CoreRuntime with no load-bearing logic outside core, which matches the layer rules in CLAUDE.md.

Things to consider

1. Fallback when the generation is unknown. destroy, #getOrCreate and the inspector key all fall back to the old actor-id-only behavior when either side's generation is undefined. If a runtime reports null at some points and a number at others, the guard is skipped. Cleanup could then close a newer generation's state. Given the fail-by-default guidance, consider asserting that the generation is always present on the native and wasm paths.
2. Inspector fallback in native.ts. When getInspector returns undefined for a superseded generation, the code falls back to getRunInspectorConfig(config.run, actorId)?.workflow, which is keyed by actor id only. Please confirm that this cannot rebind the newer generation's inspector.
3. disposeRunInspector(config.run, actorId) in both destroy paths is still keyed by actor id only, while the coordinator destroy is now generation-aware. A late cleanup from an old generation could still dispose the new generation's inspector. Pass the generation or skip the dispose when the coordinator ignored the destroy.
4. Untyped access. (actor as { generation?: number }).generation in workflow/mod.ts bypasses typing. A typed accessor on the internal actor interface would catch a rename at compile time.
5. Test coverage. The new coordinator tests are good. Missing: same-generation destroy then recreate, and a test in workflow/mod.ts showing two generations get distinct adapters and disposing one leaves the other intact. runtime-parity only stubs generation() as null, so the non-null path has no end-to-end coverage.
6. Generated file. index.d.ts appears napi-generated. Confirm it matches the generator output.

No security or performance concerns.