Rive React seems to unload items when the page is idle long enough

[csartor]

My .riv loads perfectly fine, but when the page containing said rive file is left idle for some time I get the following error, and some of the items within my rive file seem to get either hidden or unloaded.

TypeError: Cannot perform Construct on a detached ArrayBuffer
    at new Float32Array (<anonymous>)

I'm using "@rive-app/react-canvas": "^4.21.3",

Before:

After:

[aroman]

We're also running into this, even with the low-level API.

[antai0926]

I also encountered this issue. In my case, it only happens when using Rive files that contain meshes.

It’s a randomly occurring issue — sometimes it happens after just a few minutes of idling, and other times it takes several hours.

Versions with issues(@rive-app/react-canvas): 4.23.4, 4.22.1, 4.21.6
Working as expected(@rive-app/react-canvas): 4.20.2, 4.19.1, 4.18.9, 4.17.10, 4.16.7, 4.7.1(Only using useRive without useRiveFile)
Browser: Chrome 141.0.7390.123 (arm64)

[aroman]

we also use meshes in ours - and this continues to happen. clearly it's something about texturing the meshes. it's quite frustrating.

@bodymovin, i know you're mad busy, but i wonder if you are aware a workaround for this? we ship rive in production to hundreds of thousands of users, and this bites a meaningful % every day.

[bill0928]

We are writing to bring continued attention to a persistent and critical issue encountered when using the Rive runtime library. The error manifests as a runtime exception related to the allocation of an ArrayBuffer for a Float32Array.

Error Description:
The application frequently crashes with an error similar to the following:
RangeError: Invalid typed array length: -xxx at new Float32Array (<anonymous>) at [Internal Rive Code Path]

Or, in some environments:

RangeError: Array buffer allocation failed at new Float32Array (<anonymous>) at [Internal Rive Code Path]

Problem Impact:
This issue is severe as it causes application crashes, leading to a poor user experience and application instability. It often occurs during the animation lifecycle, such as when loading new Rive files, manipulating the artboard, or during complex state machine transitions. The problem is intermittent and can be difficult to reproduce consistently, making it particularly challenging to debug.

Suspected Cause:
Based on community reports and our own analysis, the root cause appears to be related to an incorrect calculation of the required buffer size for vertex or mesh data within the Rive library's WebGL or Canvas renderer. This miscalculation results in an attempt to create a Float32Array with an invalid (often negative) length, or a length that is too large for the system to allocate, triggering the ArrayBuffer allocation failure.

Request for Action:
While we acknowledge that the team is likely aware of this class of errors, we kindly request ongoing and prioritized efforts to identify and permanently resolve the underlying cause.

We believe a thorough audit of the code responsible for calculating buffer sizes for geometry and animation data is necessary. Specifically, we recommend focusing on:

Boundary Checks: Implementing rigorous validation for all calculations that determine the size of data buffers before allocating them.

Sanitization of Input Data: Ensuring that data from Rive files (.riv) is sanitized and does not lead to corrupt or invalid size calculations.

Memory Management: Reviewing the lifecycle of ArrayBuffer objects to prevent corruption from previously freed memory or race conditions.

This issue has been referenced in various community threads (e.g., GitHub issues, Discord discussions) over time, indicating it is a recurring challenge that affects multiple users and versions.

We greatly appreciate the hard work the Rive team puts into developing this fantastic tool. Thank you for your attention to this critical stability issue. We look forward to a more robust and reliable runtime in future updates.

[HayesGordon]

Thanks for the reports. We are investigating this internally.

If anyone has a full sample project that they can share that reproduces the issue, it will help resolve this faster.

[aroman]

Thanks for the reports. We are investigating this internally.

If anyone has a full sample project that they can share that reproduces the issue, it will help resolve this faster.

@HayesGordon I am happy to share our .riv file with you, but it is far from a minimal repro (it’s a pretty complex rive file), and I am not aware of any reliable way to reproduce the bug. Let me know. Our production usecase is here: https://magicgarden.gg. Only the avatars (avatarelements.riv) use this.

I will also note that our project uses both the rive-react and the low level WebGL2 renderer, both of which experience this issue, so we believe it is an issue with the rive web runtime, rather than rive-react specifically.

Thank you for looking into this.