#5809 - Poller can trigger PHP memory errors if there are lots of notifications
| Identifier | #5809 |
|---|---|
| Issue type | Minor issue (breaks specific functionality) |
| Title | Poller can trigger PHP memory errors if there are lots of notifications |
| Status | Completed |
| Tags |
Roadmap: v11 (custom) |
| Handling member | PDStig |
| Version | 11 beta1 |
| Addon | core_notifications |
| Description | If a user has a lot of notifications to be polled, this can trigger PHP out of memory errors. This can also happen if the notifications are large in size (e.g. errors with stack traces). Perhaps the poller should pull only a max of X notifications on each poll. Let's say 5. The "read all" page has the same problem. |
| Steps to reproduce | |
| Funded? | No |
| Commits |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".


Comments
* POST variables now subject to stack trace filtering
* stack trace filtering now strips strings that are too long
* If error text > 256 kb, then the web / mail notification will instead contain a path to data_custom/errors containing the error message and stack trace. Should rarely ever happen.
- If the error could not be saved to disk, then instead the error will be included in the notification, but only the first 256 kb of it.
* Performance bloat health check will fail if there are 100 or more items in data_custom/errors
The "view all" section of notifications had two fundamental problems:
a) The default max per page was 50 which could cause PHP memory issues when there are big notifications. This was reduced to 10 by default.
b) Pagination was broken anyway because the max rows was based on unread count when we are actually trying to show all (read and unread).
This hotfix fixes both cases.