[BUG] Memory exhausting by hosting large folder

[bompit1]

Describe the bug
For example, i host a 50gb folder containing source code and download all of them via concurrent script, there are many small files, while keeping GoSHS tab for monitoring Collab tab, my browser is eating RAM until the computer completely hang, i had to hard reboot it! It can easily crash 32gb RAM computer as the count keeps counting and many many logs showing... The crash happens on client-side, not hosting-side.

Desktop (please complete the following information):

• OS: macOS 26
• goshs version: 2.1.0
• Browser: Zen (Firefox-based)
• Browser version: 1.20.2b (Firefox 151.0.3) (aarch64)

[patrickhener]

Commit 7cf911a should fix this issue. Can you build from branch main and retest again for your specific case? Looking forward to hearing from you.

[bompit1]

It's still increasing insanely without stopping so i had to kill the browser process.

[bompit1]

I have a concurrent scanner for every paths/files in the root directory, after finishing, it starts downloading, the scanning part makes the memory goes high, i can see the Collab counter keeps getting up, that's why.

[patrickhener]

Is this a script you run against a running goshs instance? If so, is it a go script? You were talking about concurrency. Would you mind showing the script? Maybe I can reproduce the error.

[bompit1]

Here it is.

main.go

[patrickhener]

I commited another change, where we debounce events that reach the collab tab. Every onPROTOCOL (HTTP, DNS, ...) did a rerender, tearing down the table and rebuilding it completely. I assume this ate the memory quickly. Now I queue the events and re-render once per tick instead of synchronously. Please verify again using your environment and your script.

[bompit1]

Thanks, this patch seems fixed my issue, the peak memory of ZenCP was max 2.3gb, scanned totally 56.611 files, after finishing scanning, it completely cools down, the browser tab also not hanging, great job.

[patrickhener]

Thanks mate. Will be incorporated in release v2.1.1 as soon as I tag a new version. Until then manual build against main fixes this issue