Slow Refresh and Long Wait Times After Device Edits Make Bulk Changes Impractical

[txemi]

Is there an existing issue for this?

• I have searched the existing open and closed issues

Is your feature request related to a problem? Please describe

I am experiencing significant delays after making simple edits to devices in NetAlertX. Every time I change a device's group, type, or other attribute, the entire devices list refreshes and I must wait a long time before I can continue with the next edit.

This behavior severely impacts workflow efficiency as it makes bulk categorization or edits of many devices cumbersome and time-consuming. Even minor changes require waiting several minutes for the screen and device list to reload.

Is there any plan to optimize this process, such as implementing batch editing or reducing the reload delays? Currently, the interface is not very usable for managing many devices due to these long wait times after each edit.

Thank you for your attention and for considering improvements in this area.

Related Issue: #571

Describe the solution you'd like

Currently, when making a simple edit to a device in the interface, the entire screen refreshes and it takes a very long time before I can make the next change. This significantly hinders the usability and operability of the tool, especially when trying to categorize or group many devices efficiently.

I suggest making the interface non-blocking during these edits. Allow users to perform multiple edits without forcing a full page refresh after each change.

I understand there is a risk that a scan might overwrite a user-modified field, but in my opinion, this risk is minor compared to the current situation where it is extremely difficult to manage and organize active devices due to the slow, blocking refresh behavior.

Allowing asynchronous or batch updates would greatly improve workflow and make the tool much more practical for managing large numbers of devices.

Thank you for considering this important enhancement.

Describe alternatives you've considered

Same as described above.

Anything else?

Related to: #571

Am I willing to test this? 🧪

• I will do my best to test this feature on the netlertx-dev image when requested within 48h and report bugs to help deliver a great user experience for everyone and not to break existing installations.

Can I help implement this? 👩‍💻👨‍💻

• Yes
• No

[jokob-sk]

Hi,

There might be a delay if there are backend scans in flight.

I can disable the frontend refresh on edits, however the frontend will display invalid data until the backend refresh. Let me know if yo are OK with a solution where the devices view displays outdated values until the cache naturally expires (could be minutes due to ongoing backend scans). The UI operations wouldn't be blocked, but the downside is the data wouldn't be fresh and there would be no indication of it. Currently the loading dialog is displayed.

A workaround is for you to decrease the number of background operations, e.g. by increasing delays between scans. You can switch back to a regular schedule once most of your bulk editing is finished.

Please let em know what you think.

[adamoutler]

Any way scans can run async?

[jokob-sk]

The API endpoints are updated in the same thread as the scans so maybe there is something I can have a look at later. Maybe I could add an REST API endpoint to update the APIs async 🤔
This way the front ddn could trigger an update async and since it's handled by the web server it could happen in parallel while background scans are running

[adamoutler]

Maybe when scans kickoff, start it on a new process, then in its place, make a lock property that prevents duplication and records the process ID. The main thread can continue to respond to queries and DB/settings updates while the sub process scheduled and manages the plugins. Then unlock or check if pid died. Dunno how best to do it. Just an idea.

[txemi]

Hi @jokob-sk ,

Thank you very much for your quick response and for looking into this issue.

I'm glad to hear that there is a workaround available! I had considered changing some settings myself, but I need to clarify my goal: I suspect that making an edit specifically triggers a scan/refresh operation immediately, which is what causes the blocking delay.

Therefore, rather than globally changing the scan frequency, what I'm truly looking for is a way to respect a configurable delay (a few minutes) before any refresh or scan operation starts after a device edit has been submitted.

I would greatly appreciate it if you could confirm and suggest which specific configuration setting (or where to find it) controls this post-edit delay or the timeout before the refresh operation starts.

Once you clarify which option to adjust, I would be happy to implement this workaround right away and test its effectiveness during bulk editing.

Thank you again for your time and assistance!

Hi,

There might be a delay if there are backend scans in flight.

I can disable the frontend refresh on edits, however the frontend will display invalid data until the backend refresh. Let me know if yo are OK with a solution where the devices view displays outdated values until the cache naturally expires (could be minutes due to ongoing backend scans). The UI operations wouldn't be blocked, but the downside is the data wouldn't be fresh and there would be no indication of it. Currently the loading dialog is displayed.

A workaround is for you to decrease the number of background operations, e.g. by increasing delays between scans. You can switch back to a regular schedule once most of your bulk editing is finished.

Please let em know what you think.