finding(charts): ObjectChart's fieldOptionLabel ref workaround is removable once the i18n hook's memo holds without a provider

[os-sales]

Observation-class finding, filed unassigned while implementing #5564. Not queued — this is a cleanup that only becomes correct after #5564 lands.

Blocked-by: #5564

What is there

packages/plugin-charts/src/ObjectChart.tsx:268-271 keeps a hand-rolled ref around one i18n resolver, with this comment:

Keep a stable ref to fieldOptionLabel — the i18n hook returns a fresh function reference on every render, which would otherwise invalidate fetchData's useCallback identity and trigger an infinite refetch loop.

That is an independent consumer diagnosing, and locally working around, exactly the defect #5564 measures: useSafeFieldLabel() returned a fresh object every render outside an i18next instance, so every closure on it was fresh too.

Why it is now removable

#5564 (PR #5585) stabilises useObjectLabel's memo on both paths, so fieldOptionLabel now has a stable identity with or without a provider. The ref indirection — fieldOptionLabelRef plus the useEffect that keeps it current — no longer buys anything, and it costs the usual price of a ref-hidden dependency: fetchData no longer re-runs when the resolver genuinely does change, which is now a real possibility rather than a permanent one.

Deliberately not removed in PR #5585: that PR's fence is packages/i18n, and removing a refetch-loop guard is a change that wants its own review and its own test rather than riding along in a diff about memo identity.

Suggested shape

1. Confirm the loop does not return: drop the ref, depend on fieldOptionLabel directly in fetchData's useCallback, and pin it with a test that counts fetches across re-renders both inside and outside a provider.
2. While there, packages/plugin-timeline/src/ObjectTimeline.tsx:25-37 carries a third hand-rolled wrapper (useSafeObjectLabel, a local useObjectLabel() ?? OBJECT_LABEL_FALLBACK with a 3-member fallback) duplicating useSafeFieldLabel from @object-ui/i18n. That one is a duplication question rather than a workaround question, so it may deserve a separate card — noting it here so the sweep is not lost.

Neither is urgent; both are dead weight that reads as load-bearing to the next person, which is the cost worth removing.

[huangyiirene]

Triage (first-touch grading, 2026-08-21): finding → pm:blocked, type Task. The body already carries the machine-readable Blocked-by: #5564 line and the card is correct that the cleanup is only safe after that fix lands — removing a refetch-loop guard while the memo is still unstable would reintroduce the loop it guards. The unlock scan will return this to the queue when #5564 closes; on return, re-verify on the merged ref that PR #5585's memo stabilisation actually landed on both paths, then queue with the card's own test requirement (fetch-count pin across re-renders, inside and outside a provider).

Second item noted on the card (ObjectTimeline's third hand-rolled wrapper duplicating useSafeFieldLabel) is a separate question — on unlock, the returning triage pass should decide whether it gets its own card rather than letting it ride silently.

---

Generated by Claude Code

[huangyiirene]

Unlock (same triage round, minutes after the block was placed): #5564 closed during this round — fix PR #5585 is on origin/main (38a9568, "hold useObjectLabel's memo when no i18next instance is bound"), which is exactly the condition this card's Blocked-by: #5564 waited for. Both release checks pass (the blocked-transition comment above is the latest condition on this card; no newer merged PR landed on the card after it). pm:blocked → pm:queue.

Claim-time requirements stand as written in the grading comment: verify the memo holds on both paths on the merged ref, then remove the ref indirection with a fetch-count pin across re-renders inside and outside a provider. Size/model suggestion: S–M. The ObjectTimeline third-wrapper question noted on the card still wants its own card decision from whoever implements this.

---

Generated by Claude Code