Does Material‑UI DataGrid getRows require manual AbortController handling to prevent race conditions under concurrent scrolling?

The goal is to keep the Material‑UI DataGrid displaying up‑to‑date rows when a user scrolls quickly, which triggers many rapid getRows calls for server‑side data. Each call starts a network request, and without coordination the grid may briefly show stale data or flicker as out‑of‑order responses overwrite newer results.

The DataGrid does not cancel earlier getRows invocations, and the experimental abortSignal parameter is not documented in the stable release. Developers must therefore decide whether to add manual AbortController logic inside getRows or rely on future library changes that might enforce request ordering. This leaves the cancellation strategy undefined and creates uncertainty about latency under high concurrency.

Should the DataGrid automatically cancel previous getRows invocations when a new request is triggered? Is exposing an abortSignal parameter in the stable API sufficient to resolve race conditions? What fallback strategy should be used for browsers that lack AbortController support?