Why limit maximum number of updates to 1e6 ("Potential Infinite Loop Detected"-Exception)?

[userNotFoundByDefault]

The number of updates is limited to 1e6. This can be seen in the writeSignal-Function:

if (Updates.length > 10e5) {
    Updates = [];
    if (IS_DEV) throw new Error("Potential Infinite Loop Detected.");
    throw new Error();
}

I understand, that the limitation is there to detect infinite loops, but why does it have to delete all updates and throw an error. After all solidJS cannot know, if there is a real loop or if the application is just huge (thus the naming "potential loop"). Why not simply warn the user using the console?
I have a very big matrix-application, where each data-cell is reactive. When having big numbers of rows and columns (lets say 1600 each) and each row must create 1600 data cells (since data-cells are part of rows in html-tables, that have to be individually handled when hiding or showing columns (using the <col>-groups for that is not working fluently on all browsers)), i get easily beyond 500k updates when hiding and showing columns as the user is scrolling or interacting with the matrix (which is necessary so that the DOM is not getting too big and slowing down the browser).
When disabling this limitation solid is working just fine. Are there any issues that i am not seeing when disabling the limit? I do know, that solid might not be intended for such huge applications, but why limit the user when he knows what he is doing. Is there any way to disable/configure this limit without changing the code?

[sunnypatell]

@userNotFoundByDefault the limit is hard-coded at 10e5 (1,000,000) in packages/solid/src/reactive/signal.ts line 1355, inside writeSignal:

if (Updates!.length > 10e5) {
  Updates = [];
  if (IS_DEV) throw new Error("Potential Infinite Loop Detected.");
  throw new Error();
}

the destructive part is Updates = [] -- it wipes all pending computations before throwing, so you can't even recover. there's no config to raise or disable it.

your options:

1. batch() in chunks to reset the counter between flushes. each batch() call starts with a fresh Updates = [] (line 885 in signal.ts), so the count resets:

import { batch } from 'solid-js';

const CHUNK = 500_000;
for (let i = 0; i < cells.length; i += CHUNK) {
  batch(() => {
    for (let j = i; j < Math.min(i + CHUNK, cells.length); j++) {
      setCellValue(cells[j], newValue);
    }
  });
}

2. coarser-grained reactivity via createStore. instead of 1.6M individual signals, use a nested store where column visibility is a single signal that drives a filtered view. the store's internal proxy only notifies observers for accessed paths, so hiding a column wouldn't fan out to every cell.

3. patch-package to raise the limit. crude but works if your use case legitimately needs it.

i'd lean toward option 2 for a matrix app. 1.6M signals is a lot of reactive overhead even without the limit.