GroupedVirtuoso is crashing when trying to rerender component

[niparx]

We have component, which uses GroupedVirtuoso. Some state of our component is changed, which leads to call of render() function. As a result we have exception in GroupedVirtuoso:
Requested offset outside of the known ones, index: 0

I am 110% sure, that data, which is passed to GroupedVirtuoso component is correct.
In fact, i was able to reproduce issue with an example from Virtuoso official page.

I'm not good in web, so sorry in advance, why i did not provide a working example.

1. Go https://virtuoso.dev/grouped-numbers/;
2. Click on "Edit in StackBlitz" button;
3. Editor should be opened;
4. Before return() (15th line) add this: console.log("wassup");
5. And you'll get an error on right browser screen:

Error in /turbo_modules/react-virtuoso@0.14.0/dist/react-virtuoso.cjs.development.js (1321:13)  
Requested offset outside of the known ones, index: 0

6. Click on "reload" button on right browser screen, and it will reload without issues;
7. Modify anything in code (for example text, which is printed in console), and you'll get an error again;

So, thing is, that we are getting such exception every time, when state of the component is modified, even if data, which is passed to GroupedVirtuoso was not changed.

May be there are some workaround for this issue? Using simple VirtuosoList is not an option: we need those sticky headers.

Thanks.

[petyosi]

This is a head-scratcher. So far, I have attributed this to StackBlitz hot reload mechanism. Will look into it, but if you can give me an easier way to reproduce it, it would help a lot.

Cheers,

[niparx]

@petyosi ok, I'll try to provide normal example later today or tomorrow

[PauliusLiekis]

Just a quick update: I tried reproducing the issue in the clone of react-virtuoso repository with no luck. It doesn't seem to like empty list passed to it, but that seems to be a separate story.

On our side we're able to reproduce the issue by simply rendering GroupedVirtuoso with param groupCounts={[100]} and then hiding and showing it. It seems to be some sort of react-caching / one-frame-delay / re-layout issue.

I tried debugging it a bit and it looks like offsetTree becomes invalid. On a valid call it looks like this:

offsetTree: AATree
	root: NonNilNode
		key: 0
		value: {startIndex: 0, endIndex: 0, size: 48}
		level: 1
		left: NilNode
			level: 0		
		right: NonNilNode
			key: 48
			value: {startIndex: 1, endIndex: Infinity, size: 230}
			level: 1
			left: NilNode {level: 0}
			right: NilNode {level: 0}

when it fails it looks like this:

offsetTree: AATree
	root: NonNilNode
		key: 0
		value: {startIndex: 4, endIndex: Infinity, size: 230}
		level: 1
		left: NilNode {level: 0}
		right: NilNode {level: 0}

I know it's not much to go on - we'll try to find a better way to reproduce it tomorrow.

[PauliusLiekis]

@petyosi I found a clear way to reproduce the issue:
grouped-error.tsx.txt

Just keep pressing "Show/Hide" button until the list disappears from the screen and it says "Hidden" instead. You should see the exception in the console at that point.

Ignore the fact that sizes of items keep changing randomly - we're not doing that crazy stuff in our code. The culprit seems to be related to the fact that GroupedVirtuoso is not rendered anymore - that's the condition that we have in our code. The error seems to be 100% consistent every time the component is "removed".

How can we solve this?

[petyosi]

Thanks, I will repro the problem and release a fix - it should not be something to fix on your side.

[PauliusLiekis]

Could you tell us when you're planning to make the release?
I know you have no obligations whatsoever, but we just need to know how to proceed with our own release which is blocked by this issue.
Thanks again for looking into this.

[petyosi]

I will look into it this evening, and if something easy, I might release a fix for tomorrow. If not, I will have to examine it over the weekend.

[petyosi]

I found one possible cause - can you test v0.14.1?

[PauliusLiekis]

I seem to be unable to reproduce the issue. I'll give the build to QA in the morning to make sure it's solid. Thanks again!

[PauliusLiekis]

It seems to be fine now. Amazing!