fix: batch bulk subscriber creation to prevent network error (#158)

[ALIIQBAL786]

Problem

When creating multiple subscribers with a large `userNumber`, the frontend crashes with a Network Error.

Root cause: The original `onCreate` loop fired all N `axios.post()` calls simultaneously without awaiting. For large counts (e.g. 10,000), this overwhelms the browser's networking stack. Additionally, `navigation("/subscriber")` was called inside every `.then()`, so the component unmounted on the first success while thousands of in-flight requests continued updating dead state.

Fix

• Process requests in controlled batches of 10 using `Promise.allSettled`
• Navigate exactly once after all batches complete
• Show a live progress bar with count (e.g. "Creating 450 / 1000")
• Show an error summary when any requests fail (instead of per-request alerts)
• Disable the CREATE button while the operation is in progress

Tested

• 5 subscribers — completes and navigates correctly
• 1000 subscribers — progress bar updates, navigates on completion
• With simulated 20% failure rate — error summary displays correctly
• Double-click CREATE — button disabled, no duplicate requests

Fixes #158

[Alonza0314]

Hi @ALIIQBAL786,

This is a solid improvement to the creation procedure—nice work on that.

I do have a question regarding how you managed to create such a large number of UEs. Did you use the frontend to add them, or did you rely on backend APIs or scripts?

As for the issue itself, my understanding is that the reporter is pointing out that the subscriber page panics when handling around 10K UEs, rather than focusing on the creation procedure.

Happy to discuss further!

Cheers,
Alonza

[ALIIQBAL786]

Tested against the real free5GC Docker stack. Summary of all changes:

Bulk create fix (Issue #158)
The original loop fired all requests simultaneously without awaiting, crashing the browser network stack. Fixed by processing
requests in batches of 300 using Promise.allSettled, navigating exactly once after all batches complete, and showing a progress bar
with per-subscriber error collection.

Subscriber list virtualization
react-window inside MUI TableBody rendered either 0 rows or all rows at once. Fixed by moving the virtual list into a plain Box and
using CSS Grid for column alignment. Tested with 50,000 subscribers — only visible rows render and scrolling is smooth.

Reviewer feedback
Added isLoading state to prevent empty-state flash on tab switch/refresh. Moved VirtualRow outside the component for stable
reference. Used useMemo for filtered data and useCallback for row handlers. Selection keyed by ueId+plmnID. Added
double-confirmation dialog for bulk deletes ≥ 100.

Progress bar fix
setLoading(true) in onCreate was triggering the edit-mode loading guard, hiding the form and progress bar. Removed those calls —
loading is only for prefilling the edit form.

Bulk delete fix
Large selections were silently dropped (no error shown, rows unchanged). Fixed by batching DELETE requests at 500 items each with a
progress bar, matching the create pattern.

[solar224]

@ALIIQBAL786 One thing I'd like to flag — the current approach replaces MUI's semantic <Table> / <TableHead> / <TableBody> / <TableRow> / <TableCell> components with raw <Box> elements styled via inline sx={{}} props and hardcoded color values (e.g. #fafafa, rgba(25,118,210,0.08)). This diverges from the styling patterns used across the rest of the webconsole (such as AnalysisList, ProfileList, TenantList, etc.), where MUI table components handle theming automatically with no hardcoded colors.

To keep things consistent and theme-friendly, could you consider one of the following?

• Use MUI theme tokens — replace hardcoded values with references like "divider", "action.hover", "background.default", etc., so the styles adapt automatically if the theme changes.
• Extract to a CSS file — create a dedicated SubscriberList.css (similar to how the project uses App.css / index.css) to keep the styling separate from the component logic.

Also, a minor housekeeping note — there are quite a few comments that read more like commit messages or PR descriptions rather than long-term code documentation. Could you clean these up and keep only comments that explain non-obvious decisions?

Either approach would help keep the codebase consistent and easier to maintain going forward. Let me know what you think!

[ALIIQBAL786]

Thanks for the review!

You're right about the hardcoded colors, I've replaced all of them with MUI theme tokens ("divider", "action.selected", "background.default", etc.) in the latest commit, so they'll adapt automatically with the theme. Comments have been cleaned up too, kept only the one explaining the react-window height constraint since that's genuinely non-obvious.

On the structure, that one's unfortunately a hard constraint from react-window. It renders each row into an absolutely-positioned

, so putting elements inside it produces invalid HTML and breaks the layout. It also prevents react-window from measuring the container height correctly, which causes it to render 0 rows. CSS Grid with a shared column template is the standard workaround for this, it keeps the visual alignment consistent with what would give you, just without the semantic wrapper.

Let me know if anything else needs adjusting!

[ALIIQBAL786]

Thanks for the detailed review @solar224, really appreciate you going through it carefully!

Since the PR is already merged, I'll pick these up in a follow-up. The plan:

• Add a proper guard for userNumber before the loop so undefined surfaces as a clear error rather than silently creating 0 subscribers
• Build payloads lazily inside the batch loop instead of pre-allocating the full array upfront
• Narrow the useCallback dependency from [props] to [props.setRefresh]
• Wrap rowProps in useMemo
• Import the actual ariaAttributes type from react-window v2 instead of the manual declaration
• Drop the double confirmation for bulk delete and collect per-batch errors the same way the create flow does
• Move BATCH_SIZE, ROW_HEIGHT, MAX_LIST_HEIGHT, and the delete thresholds into config.tsx so they're easy to tune
• Remove @types/react-window and let react-window v2's built-in types take over

Will open a follow-up PR once these are ready!

[solar224]

@ALIIQBAL786 Thanks for the quick reply and for outlining this detailed follow-up plan!

Just wanted to give you a quick heads-up that I've actually already started working on these subsequent modifications on my end. So, no need to spend your time opening a new PR for this—I'll take it from here.

Really appreciate your contribution and all your work on the initial PR!

BR,

[ALIIQBAL786]

Thanks for the heads-up @solar224, and happy to hand it off! Looking forward to seeing your improvements. Appreciate the kind words too!