kunwp1 opened a new issue, #5586:
URL: https://github.com/apache/texera/issues/5586
### What happened?
Dropping (or selecting) a large number of files — around 1000 — at once into
a dataset crashes the browser tab (renderer out-of-memory / "Aw, Snap!"). The
page becomes unresponsive and the tab dies while the uploads are in progress;
the upload never completes.
**Expected:** uploading many files at once should proceed (uploads are
already throttled to a few concurrent transfers) without exhausting memory or
crashing the tab.
### How to reproduce?
1. Open a dataset you have write access to (the dataset detail page).
2. Drag-and-drop ~1000 files into the uploader (or pick ~1000 files via the
file picker).
3. Watch the tab's memory climb — the UI becomes unresponsive and the tab
crashes while uploads are running.
### Root cause (analysis)
The crash is in the **rendering of the upload UI**, not in the upload
transfer itself (uploads are correctly throttled to `maxConcurrentFiles`,
default 3):
- With 3 concurrent uploads, the remaining ~997 files sit in the pending
queue, and the **"Pending" panel renders one ng-zorro row per queued file**
(button + tooltip + icon) with no virtualization (`*ngFor`, no `trackBy`). The
**"Finished"/staged-changes list** likewise renders one row per staged object.
- The pending list is bound to a `queuedFileNames` getter that **allocates a
new array on every change-detection cycle**.
- Each active upload emits an XHR `progress` event many times per second,
and every emission triggers Angular change detection. So while ~1000 rows sit
in the DOM, the queue array is re-allocated and the list re-diffed on every
progress tick → runaway memory/CPU → the tab runs out of memory.
Relevant files (under
`frontend/src/app/dashboard/component/user/user-dataset/user-dataset-explorer/`):
`dataset-detail.component.{ts,html}`,
`user-dataset-staged-objects-list/user-dataset-staged-objects-list.component.{ts,html}`.
### Proposed fix
- Virtualize the Pending and Finished lists with `cdk-virtual-scroll` so the
rendered DOM stays bounded to visible rows regardless of file count.
- Replace the allocating `queuedFileNames` getter with a cached field
updated only on queue mutations, and add `trackBy`.
### Version/Branch
1.3.0-incubating-SNAPSHOT (main)
### What browsers are you seeing the problem on?
Chrome (Chromium-based). The root cause is browser-agnostic memory
exhaustion, so other browsers are likely affected as well.
### Relevant log output
Chrome shows an "Aw, Snap! — Out of memory" / renderer crash. There is
typically no JavaScript exception in the console — it is memory exhaustion, not
a thrown error.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
