Memory leak in Settings > IRC > View

[MagiX13]

Version
dev

Describe the bug
Memory usage of tab explodes at some point

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Settings'
2. Click on 'IRC'
3. Select an active channel
4. Click on View
5. Wait and monitor memory usage of tab

Expected behavior
No memory leak

Desktop (please complete the following information):

• OS: Arch
• Browser Firefox
• Version 125

Additional context
I have the impression that the current behaviour doesn't add new lines that were received, but adds the most recent $number of lines. The number appears to be large and thus memory usage of the tab starts increasing and increasing with each new announcement. You can also find duplicate announcements by scrolling and searching through the growing list of announces.

[martylukyy]

Do you run a reverse proxy in front of autobrr?
If yes, which one?

[MagiX13]

I'm using nginx indeed. For some reason I can no longer access it directly via http://$ip:$port/$basedir, so difficult to test without

[martylukyy]

Yeah, you would need to remove the baseURL directive in the config.tol to try it without, but no need to do that.
The issue most likely nginx timing out the eventstream for the IRC logs
causing it to refetch all the logs of the respective IRC logs opened over and over again after a minute.
So it's not really a memory leak but i see where you are coming from! 😄

Not sure what we can do something to keep that alive some how - need to discuss that internally.
In the meanwhile as a workaround you could add proxy_read_timeout 3600; to the autobrr location directive in nginx
in case you are experiencing severe problems due to that.

[zze0s]

As marty mentions above we have identified the issue and it is indeed related to keep-alive.

ServerSentEvents do not use any ping events to keep connections alive, at least not with the library we are using. That leads to the proxy_read_timeout to then refetch the request and because we send up to 1000 events per channel you get all those events over and over if there are no announces during the proxy_read_timeout interval.

We can add a Ping but we need to make changes to the library to exclude those messages from the event store so we get back the correct data.

While this is annoying I don't consider it that critical because I don't think most users sit with the channel log open for hours a day. I could be wrong tho :)

We'll fix it eventually but not for the next release.