[Image] | (fix) | Batch setState calls in setupGraphie to prevent infinite loop

[Myranae]

Problem

SvgImage.setupGraphie called setState once per label inside a loop. Because this.state doesn't update synchronously between setState calls in class components, each iteration spread the same stale base — leaving labelsRendered in an inconsistent intermediate state. An async prop change from ImageComponent's zoomSize effect would land mid-loop, bypassing shouldComponentUpdate and exposing Graphie to the bad state. Graphie interpreted this as a meaningful options change, re-ran setupGraphie, and triggered another setState storm — repeating until React hit its update depth limit.

Solution

Accumulate all label updates into a plain object during the loop and call setState once. The state transition is now atomic, eliminating intermediate inconsistent states and the re-render storm they caused. The updater also uses a functional form (prev => ...) so the merge always reads from the latest committed state rather than this.state at call time.

Issue: LEMS-3853

Test plan:

• Confirm all CI checks pass
• Confirm Graphies in image widgets function as before (no regressions) using a FE test branch
• Confirm the Sentry issue linked in the ticket stops producing new events after deploy
• Verify on mobile (the zoomSize effect only fires when scaleFF is off, and mobile is the most common path
  where that matters)

Completed with Claude Code

[github-actions]

🗄️ Schema Change: No Changes ✅

[github-actions]

Size Change: +21 B (0%)

Total Size: 486 kB

Filename	Size	Change
packages/perseus/dist/es/index.js	188 kB	+21 B (+0.01%)

ℹ️ View Unchanged

Filename	Size
packages/kas/dist/es/index.js	20.5 kB
packages/keypad-context/dist/es/index.js	1 kB
packages/kmath/dist/es/index.js	5.96 kB
packages/math-input/dist/es/index.js	98.5 kB
packages/math-input/dist/es/strings.js	1.61 kB
packages/perseus-core/dist/es/index.item-splitting.js	11.8 kB
packages/perseus-core/dist/es/index.js	24.9 kB
packages/perseus-editor/dist/es/index.js	100 kB
packages/perseus-linter/dist/es/index.js	8.82 kB
packages/perseus-score/dist/es/index.js	9.4 kB
packages/perseus-utils/dist/es/index.js	403 B
packages/perseus/dist/es/strings.js	7.47 kB
packages/pure-markdown/dist/es/index.js	1.39 kB
packages/simple-markdown/dist/es/index.js	6.71 kB

_{compressed-size-action}

[github-actions]

🛠️ Item Splitting: No Changes ✅

[github-actions]

npm Snapshot: Published

Good news!! We've packaged up the latest commit from this PR (d95c2ca) and published it to npm. You
can install it using the tag PR3329.

Example:

pnpm add @khanacademy/perseus@PR3329

If you are working in Khan Academy's frontend, you can run the below command.

./dev/tools/bump_perseus_version.ts -t PR3329

If you are working in Khan Academy's webapp, you can run the below command.

./dev/tools/bump_perseus_version.js -t PR3329

[Myranae]

Will remove this before landing!

[claude]

LGTM — straightforward batching of setState calls to fix infinite loop.

Extended reasoning...

Overview

This PR fixes a React "Maximum update depth exceeded" error (LEMS-3853) by batching setState calls in SvgImage.setupGraphie. The only meaningful code change is ~10 lines in packages/perseus/src/components/svg-image.tsx: moving per-label setState calls out of a loop into a single batched call with a functional updater (prev) => .... The other files are a changeset and an investigation plan doc (author noted it will be removed before landing).

Security risks

None. The change is purely a React state management fix — no user input handling, auth, or data exposure changes.

Level of scrutiny

Low scrutiny needed. The fix applies a well-established React pattern (accumulate updates, single setState with functional updater). The before/after behavior is easy to reason about, and the PR description thoroughly explains the root cause. The change is small and self-contained.

Other factors

No bugs were found by the automated bug hunting system. The author has an outstanding note to remove .claude/plans/lems-3853-summary.md before landing, but that is a non-code housekeeping item that does not affect correctness. The bundle size impact is negligible (+18 B).

[jeremywiebe]

That makes sense to me!

Also, cool that our new STOPSHIP for claude plans is triggering.

[nishasy]

This makes sense to me. I really wish I could be more confident about the results of this change, but unfortunately, I don't think there's a good way to test this.