RangeError Maximum call stack size exceeded

[SAMBIT20]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Steps to reproduce 🕹

Link to live example:
codesandbox
Steps:

1. Uncomment Line no 15 - 17

Current behavior 😯

Expected behavior 🤔

No response

Context 🔦

No response

Your environment 🌎

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Order ID or Support key 💳 (optional)

62159

[MBilalShafi]

You are supposed to have a unique value in the field property for each colDef. Is there a specific reason you want to use the same field name in two colDef objects?

[SAMBIT20]

@MBilalShafi Although there is no known cause, the component has occasionally crashed when the backend delivered duplicate field data.

[fingeromer]

It also happen to us on version @mui/[email protected]

We don't have duplicate field props

[fingeromer]

react-dom.development.js:22839 Uncaught RangeError: Maximum call stack size exceeded
    at Array.map (<anonymous>)
    at gridColumnsSelector.js:24:154
    at recomputationWrapper (index.js:67:25)
    at memoized (defaultMemoize.js:123:20)
    at dependenciesChecker (index.js:81:40)
    at memoized (defaultMemoize.js:123:20)
    at selector (createSelector.js:96:89)
    at dependenciesChecker (index.js:77:37)
    at memoized (defaultMemoize.js:123:20)
    at selector (createSelector.js:96:89)


react_devtools_backend_compact.js:2367 The above error occurred in the <ForwardRef(DataGridPro)> component:

    at DataGridPro (http://localhost:3000/node_modules/.vite/deps/@mui_x-data-grid-pro.js?v=0b2c3f5b:30315:17)
    at DataGrid (http://localhost:3000/src/common/components/DesignSystem/DataGrid.tsx?t=1688388800829:89:3)
    at div
    at http://localhost:3000/node_modules/.vite/deps/chunk-PMLE5DPL.js?v=00343835:1672:49
    at Grid2 (http://localhost:3000/node_modules/.vite/deps/chunk-QGSFWC5N.js?v=00343835:4345:24)
    at ImageVulnerabilities (http://localhost:3000/src/pages/image-page/components/ImageVulnerabilities.tsx?t=1688388796078:51:3)
    at div
    at http://localhost:3000/node_modules/.vite/deps/chunk-PMLE5DPL.js?v=00343835:1672:49
    at TabPanel4 (http://localhost:3000/node_modules/.vite/deps/@mui_lab.js?v=bb780fa2:9855:17)
    at TabContext (http://localhost:3000/node_modules/.vite/deps/@mui_lab.js?v=bb780fa2:9724:5)
    at div
    at http://localhost:3000/node_modules/.vite/deps/chunk-PMLE5DPL.js?v=00343835:1672:49
    at Grid2 (http://localhost:3000/node_modules/.vite/deps/chunk-QGSFWC5N.js?v=00343835:4345:24)
    at http://localhost:3000/node_modules/.vite/deps/chunk-PMLE5DPL.js?v=00343835:1672:49
    at div
    at http://localhost:3000/node_modules/.vite/deps/chunk-PMLE5DPL.js?v=00343835:1672:49
    at Grid2 (http://localhost:3000/node_modules/.vite/deps/chunk-QGSFWC5N.js?v=00343835:4345:24)
    at div
    at http://localhost:3000/node_modules/.vite/deps/chunk-PMLE5DPL.js?v=00343835:1672:49
    at Box3 (http://localhost:3000/node_modules/.vite/deps/chunk-QGSFWC5N.js?v=00343835:1875:19)
    at div
    at http://localhost:3000/node_modules/.vite/deps/chunk-PMLE5DPL.js?v=00343835:1672:49
    at Box3 (http://localhost:3000/node_modules/.vite/deps/chunk-QGSFWC5N.js?v=00343835:1875:19)
    at Page (http://localhost:3000/src/common/components/AppCommon/Page.tsx:21:3)
    at ImagePage (http://localhost:3000/src/pages/image-page/components/ImagePage.tsx?t=1688388670162:62:39)
    at div
    at http://localhost:3000/node_modules/.vite/deps/chunk-PMLE5DPL.js?v=00343835:1672:49
    at Grid2 (http://localhost:3000/node_modules/.vite/deps/chunk-QGSFWC5N.js?v=00343835:4345:24)
    at RenderEmptyWhenNotAuthed (http://localhost:3000/src/common/components/App/App.tsx?t=1688388670162:56:5)
    at RenderedRoute (http://localhost:3000/node_modules/.vite/deps/react-router-dom.js?v=6c2c32f8:3265:5)
    at Routes (http://localhost:3000/node_modules/.vite/deps/react-router-dom.js?v=6c2c32f8:3718:5)
    at div
    at http://localhost:3000/node_modules/.vite/deps/chunk-PMLE5DPL.js?v=00343835:1672:49
    at Box3 (http://localhost:3000/node_modules/.vite/deps/chunk-QGSFWC5N.js?v=00343835:1875:19)
    at App (http://localhost:3000/src/common/components/App/App.tsx?t=1688388670162:51:7)
    at JiraContextWrapper (http://localhost:3000/src/packages/jira/jira.context.tsx:46:33)
    at IgnoreIssueContextWrapper (http://localhost:3000/src/packages/ignore-issue/ignore-issue.context.tsx:47:33)
    at CveSidePanelContextWrapper (http://localhost:3000/src/packages/cve/CveSidePanel/cve.context.tsx:46:33)
    at NamespaceCriticalityContextWrapper (http://localhost:3000/src/packages/namespace/namespace.context.tsx:47:33)
    at IndicationContextWrapper (http://localhost:3000/src/common/hooks/featureHooks/useIndication/indication.context.tsx:46:33)
    at AppWithContext (http://localhost:3000/src/common/components/App/wrapPage.tsx:53:3)
    at AuthProvider (http://localhost:3000/node_modules/.vite/deps/react-oidc-context.js?v=357fcc5c:107:5)
    at QueryClientProvider2 (http://localhost:3000/node_modules/.vite/deps/react-query.js?v=d47f95bd:2661:21)
    at NoSsr (http://localhost:3000/node_modules/.vite/deps/chunk-UJVFWMIH.js?v=00343835:1406:5)
    at ThemeProvider (http://localhost:3000/node_modules/.vite/deps/chunk-QGSFWC5N.js?v=00343835:2527:5)
    at ThemeProvider2 (http://localhost:3000/node_modules/.vite/deps/chunk-QGSFWC5N.js?v=00343835:2613:5)
    at ThemeProvider (http://localhost:3000/node_modules/.vite/deps/chunk-X5KSH6KJ.js?v=00343835:289:12)
    at Router (http://localhost:3000/node_modules/.vite/deps/react-router-dom.js?v=6c2c32f8:3665:15)
    at BrowserRouter (http://localhost:3000/node_modules/.vite/deps/react-router-dom.js?v=6c2c32f8:4132:5)
    at Wrapper

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://reactjs.org/link/error-boundaries to learn more about error boundaries.

[MBilalShafi]

@fingeromer Could you provide a live minimal reproduction on codesandbox or similar (or a snippet of the columns prop)?
You could use https://codesandbox.io/s/datagrid-v5-quick-start-54iz1 as the starting point.

[MBilalShafi]

@SAMBIT20 It goes into an infinite loop for flex (same field name) because we store the values for the columns in a lookup based on field attribute and when accessing the value, it can not differentiate the value between two different objects with the same field name, you could either clean the colDefs received from the server before passing down to the Grid, or we could check for the unique columns only in loopOverFlexItems:

diff --git a/packages/grid/x-data-grid/src/hooks/features/columns/gridColumnsUtils.ts b/packages/grid/x-data-grid/src/hooks/features/columns/gridColumnsUtils.ts
index 2b1f02e94..c714d17b8 100644
--- a/packages/grid/x-data-grid/src/hooks/features/columns/gridColumnsUtils.ts
+++ b/packages/grid/x-data-grid/src/hooks/features/columns/gridColumnsUtils.ts
@@ -42,6 +42,7 @@ export function computeFlexColumnsWidth({
     maxWidth?: number;
   }[];
 }) {
+  const uniqueFlexColumns = new Set<GridColDef['field']>(flexColumns.map((col) => col.field));
   const flexColumnsLookup: {
     all: Record<
       GridColDef['field'],
@@ -68,7 +69,7 @@ export function computeFlexColumnsWidth({
   // Step 5 of https://drafts.csswg.org/css-flexbox-1/#resolve-flexible-lengths
   function loopOverFlexItems() {
     // 5a: If all the flex items on the line are frozen, free space has been distributed.
-    if (flexColumnsLookup.frozenFields.length === flexColumns.length) {
+    if (flexColumnsLookup.frozenFields.length === uniqueFlexColumns.size) {
       return;
     }

If the intention though is to support proper flex positioning for such columns (those with the same field value), we might need to change the data structure used in loopOverFlexItems, but should we? Since ideally the field property should be unique.

@cherniavskii Any opinion on this?

[cherniavskii]

@MBilalShafi Thanks for looking into it!

If the intention though is to support proper flex positioning for such columns (those with the same field value), we might need to change the data structure used in loopOverFlexItems, but should we?

I don't think we should, a lot of things won't work with duplicated fields anyway 🙂
The diff makes sense to me, I'll open a PR with a unit test 👍

[fingeromer]

Untitled_.Jul.3.2023.8_22.PM.webm

https://codesandbox.io/s/recursing-cloud-qwvfdz
It also happen when there are no duplicate fields, and when I change the zoom in my browser.
@MBilalShafi

[cherniavskii]

Thanks, @fingeromer!
I can reproduce the issue without changing the page zoom using this demo: https://codesandbox.io/s/musing-morning-2wm9cf?file=/src/App.js
It's caused by the floating point precision error:

const containerWidth = 1582;
const colNumber = 6;
const colWidth = containerWidth / colNumber; // 263.6666666666667
colWidth * 6 // 1582
colWidth * 5 + colWidth // 1582.0000000000002

It's a regression caused by #9516

[seemX17]

Fixed with latest version 6.12.1 :) Was facing similar issue on 1820*937 screen size

[cherniavskii]

@seemX17 Can you open an issue with a reproduction example? Thanks!

[seemX17]

@cherniavskii As I have mentioned in the above comment the issue was resolved with the latest version. Have added the screenshot for the developer reference but If I come across the same bug again will create a new issue with an example. Thanks!

[cherniavskii]

@seemX17 Sorry, somehow I misunderstood your comment and thought that you experienced this issue with the latest version 😅