fix(store): remove eager state mutation in batch, fix race window

[ionfwsrijan]

Description

In batch(), setState eagerly assigns state = nextState at line 310 before the microtask commit runs. This creates a race window where any synchronous non-batched setState() or mutate() call that reads getState() sees the intermediate batched value and writes changes that are later silently overwritten by the batch's commit().

The same bug exists in mutate() at line 389.

Fix

1. Removed state = nextState inside the batch path in setState (line 310) — only commit() sets final state
2. Removed state = nextState inside the batch path in mutate (line 389) — moved to non-batch path only
3. Updated getState() to return pending batch nextState when _batchDepth > 0, so in-batch reads see correct intermediate state
4. Updated setState function updaters to receive pending batch state when inside a batch
5. Updated mutate to produce from pending batch state when inside a batch

Tests

• setState outside batch after batch call is not overwritten by commit
• getState inside batch returns pending batch state

Closes #1627

Summary by CodeRabbit

• Bug Fixes
  • Improved batching behavior for state updates and reads. getState() now correctly reflects pending updates during an active batch, and state mutations within batches compute from the in-flight state rather than the previously committed state, ensuring more consistent behavior when batching multiple updates together.

[coderabbitai]

Warning

Review limit reached

@ionfwsrijan, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 14 minutes and 35 seconds. Learn how PR review limits work.

To continue reviewing without waiting, enable usage-based billing in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 76195843-dcc7-4bf8-88bb-0f949eb5a0e2

📥 Commits

Reviewing files that changed from the base of the PR and between ecaaeb8 and 8c06994.

📒 Files selected for processing (1)

• packages/store/src/store.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[ionfwsrijan]

@Karanjot786 Please review this