Excessive Device Logs lead to Home Assistant OOM

### Checklist - [x] I have updated to the latest available Home Assistant version. - [x] I have cleared the cache of my browser. - [x] I have tried a different browser to see if it is related to my browser. - [x] I have tried reproducing the issue in [safe mode](https://www.home-assistant.io/blog/2023/11/01/release-202311/#restarting-into-safe-mode) to rule out problems with unsupported custom resources. ### Describe the issue you are experiencing Bug - Loading Device "Activity" log causes Oom when it contains many entries. Summary: Due to an issue within the config for an esphome device here, that device generated many many thousands of state changes. Viewing the Device page loaded the other elements, but the Activity pane remained showing the loading animation. At the same time HA crashed and restarted without logs. After restart, reloading the same page consistently causes a restart. Other device pages load without issue, including Activity pane Checking the VM's syslog, I saw that oomkiller had killed Home Assistant because it requested more than the 1Gb of ram set in its docker-compose.yml Raising the compose limit to 2Gb allowed the Device page to fully load (taking a minute or so to populate the Activity pane) htop shows HA to be using around 1.7Gb of ram at this point, when it normally runs less than 1Gb, suggesting it's loading around 1Gb worth of recent Activity logs. Whilst one can argue that 1Gb may not be sufficient for HA to run, I feel that limiting the maximum logs loaded into Activity (Eg, a hardcoded LIMIT 1000 or even less) would provide sufficient history in every case but protect HA from using excessive memory. ### Describe the behavior you expected For HA Devices Page to load the most recent logs, up to a reasonable number, rather than try to load all available logs and exceed memory available. ### Steps to reproduce the issue 1. Have a broken device that generates hundreds of thousands of logs. (My strobe was flapping 2 or 4 times a second, each generating an on/off log) for several hours before I noticed. 2. View that device's pane. (Integrations -> Esphome -> Device) 3. Watch HA be oomkilled and restarted if 1Gb constrained (or presumably less for testing) ... ### What version of Home Assistant Core has the issue? 2026.8.2 ### What was the last working version of Home Assistant Core? _No response_ ### In which browser are you experiencing the issue? Firefox 153.04 ### Which operating system are you using to run this browser? Windows 11 ### State of relevant entities ```txt (More details but not required reading) Note: Raising memory limit within docker-compose from 1Gb to 2Gb stops the crashing. HA and Esphome Builder all fully up to date. Those are the only things running on a Debian vm with 4Gb ram. My HA setup is mature and pretty complex. Background: I have 9 esphome devices. One such controls a strobe light by turning it on and off again twice a second. This has worked well for two years but recently started activating the trigger when HA restarted. This isn't the bug - I fixed it by adding a default_state to the esphome yaml using building. Easy, quick and fixed that issue. The problem came when I viewed that device's "Device Info" page in Integrations -> Esphome -> ThatDevice. Most of the page loaded, apart from the "Activity" pane, which continually showed the loading animation. And **Home Assistant restarted** Reloading this page consistently crashes HA (Running in docker. HA logs don't show anything apart from normal activity until the normal start-up logs.) I can view other esphome and non-esphome device pages fine, including the activity log, but every time I now visit this one device, HA restarts. The VM's syslogs do show the issue - an out of memory kill of HA by cgroup I believe that my faulty device created so many logs in a short time that loading them into Activity Log causes HA to request more memory than is available. On checking, I did have a 1Gb memory limit in my docker-compose.yml which is consistent with the memory exceeded by HA when oomkiller stepped in. (Ie, both docker and oomkiller were doing what they were supposed to) My local fix: I raised the compose limit to 2G and restarted HA. The device page now shows, albiet after a long time as it loads all logs into memory. ``` ### Problem-relevant frontend configuration ```yaml ``` ### JavaScript errors shown in your browser console/inspector ```txt ``` ### Additional information _No response_