You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
[plugin-dashboard] a table widget with inline static data crashes into the error boundary — "Maximum update depth exceeded" #4618
Measured while implementing (d1) of #4600 (PR #4615), probing which widget data surfaces render in the docs gallery. Filed unassigned; not fixed there — packages/plugin-dashboard/src/** was outside that card's scope. Duplicate-searched (keyword + data-table path): no open issue covers it.
Reproduction, measured on origin/main @ c1d939f7f
Rendered through the real SchemaRenderer, with @object-ui/components + @object-ui/plugin-dashboard + @object-ui/plugin-charts registered:
Recent InvoicesComponent "data-table" failed to render
Maximum update depth exceeded. This can happen when a component repeatedly calls
setState inside componentWillUpdate or componentDidUpdate. React limits the
number of nested updates to prevent infinite loops.
Retry
The same probe rendered bar, line, area, donut and metric widgets from the identical static surface with no alert and a mounted chart container, so the defect is specific to the table family (dispatch.family === 'table'), which DashboardRenderer.getComponentSchema maps to:
Not established here: whether the loop lives in data-table itself or in what the dashboard spreads onto it (note ...options spreads the author's options, including the data key, before data is set — so data is passed twice from two derivations). A one-line reproduction against data-table directly would settle that, and is the obvious first step.
Why it matters
table is a spec-enumerated dashboard widget type and the static options.data surface is live and documented (content/docs/guide/dashboard-filters.md describes static-data widgets as a supported, unfiltered surface). No catalog entry exercises it, which is why nothing caught this — PR #4615 chose chart/metric surfaces for the entries it rewrote and never landed on table.
Adjacent, not the same: this is the STATIC path. The provider: 'object' path routes to object-data-table instead and is untested here.
PM ruling (delegated, veto window open): diagnose-first, then the minimal correct fix. The filing's lead ("DashboardRenderer passes data twice — via ...options and the derived key") is a HYPOTHESIS to verify, not the ruling: reproduce the crash red-first exactly as filed (static-data table widget → error boundary "Maximum update depth exceeded" at packages/components/src/renderers/complex/data-table.tsx:788), trace the actual re-render loop (the usual shapes: an unstable prop identity feeding a useEffect/useState sync, or a controlled/uncontrolled flip), and fix at the CAUSE — in whichever package owns it (components' data-table renderer or plugin-dashboard's node construction; both surfaces are currently free). Must-not-change: every other data-table consumer (grid/list/detail radius), and the dashboard's other widget families. If the fix lands in components, sweep data-table's full consumer radius; if in plugin-dashboard, mirror-check DashboardGridLayout's equivalent construction (post-#4613/#4614 both build these nodes). Grading by measurement; behavior fix ⇒ patch or minor per the established precedents; never major. Standard playbook: worktree, red-first verbatim, reverse verification (no git stash), repo-root vitest, .d.ts both ways, gate battery, DRAFT PR (Fixes #4618), CI via MCP only, no flip/arm.
Mutual exclusion: no other seat in flight; ⛔ content/docs/releases/**; ⛔ the #4616 seat (dispatching in parallel) owns apps/site/** + examples/schema-catalog/test/** — if your fix needs a catalog-side pin, coordinate by leaving it to #4616's render-pin extension and say so.
Activity
yinlianghui commentedon Aug 14, 2026
CLAIM — session
session_017Qqyix2QcnpUC9XeYVDzx3, branchclaude/issue-4618-datatable-update-depth.PM ruling (delegated, veto window open): diagnose-first, then the minimal correct fix. The filing's lead ("DashboardRenderer passes
datatwice — via...optionsand the derived key") is a HYPOTHESIS to verify, not the ruling: reproduce the crash red-first exactly as filed (static-datatablewidget → error boundary "Maximum update depth exceeded" atpackages/components/src/renderers/complex/data-table.tsx:788), trace the actual re-render loop (the usual shapes: an unstable prop identity feeding auseEffect/useStatesync, or a controlled/uncontrolled flip), and fix at the CAUSE — in whichever package owns it (components' data-table renderer or plugin-dashboard's node construction; both surfaces are currently free). Must-not-change: every other data-table consumer (grid/list/detail radius), and the dashboard's other widget families. If the fix lands in components, sweep data-table's full consumer radius; if in plugin-dashboard, mirror-checkDashboardGridLayout's equivalent construction (post-#4613/#4614 both build these nodes). Grading by measurement; behavior fix ⇒ patch or minor per the established precedents; never major. Standard playbook: worktree, red-first verbatim, reverse verification (no git stash), repo-root vitest, .d.ts both ways, gate battery, DRAFT PR (Fixes #4618), CI via MCP only, no flip/arm.Mutual exclusion: no other seat in flight; ⛔
content/docs/releases/**; ⛔ the #4616 seat (dispatching in parallel) ownsapps/site/**+examples/schema-catalog/test/**— if your fix needs a catalog-side pin, coordinate by leaving it to #4616's render-pin extension and say so.Generated by Claude Code
Generated by Claude Code
refactor(components): type the data-table loop guard without `any` (#…
fix(components,plugin-dashboard): the static-data table widget render…
plugin-dashboard: hoist the no-rows-yet empty to module scope (#4629)
plugin-dashboard: hoist the "no rows yet" empty to module scope in Ob…