[BUG] Pages with extreme quanities of a search term cause search formatting to timeout #5475

New Issue

OVERLORD · 2026-02-05T10:05:44+03:00

OVERLORD commented

2026-02-05 10:05:44 +03:00

Originally created by @Mikrz on GitHub (Oct 30, 2025).

One of my organization's DBA's had created an SQL refactoring page containing many thousands of UPDATE statements, which broke Bookstack search any time someone searched for the term "update". I tracked down the timeout to the search term highlighting function, as it does not appear to have any limit to how many terms it will search for.

This is understandable, as there should not be multi-thousand hit documents uploaded in this manner, but unfortunately once it happened it was not obvious where the problem was.

I believe one of two options (or both) would be a good way to make this a bit more manageable.

Add a limit to the number of instances of a term to hightlight, maybe 20 to 30, and move on to the next document once this limit is reached. This would be rather easy to implement as an additional condition to the while statement.
Flag documents passing this limit, or a much higher limit, to indicate to users and admins that this particular search result has an extreme number of hits for the given search term. This is clearly much more work, both in logic and UI adjustment.

652124abaf/app/Search/SearchResultsFormatter.php (L85)

I fully understand that this:

is absolute insanity to put in a wiki page, but unfortunately people always find a way...

Originally created by @Mikrz on GitHub (Oct 30, 2025). One of my organization's DBA's had created an SQL refactoring page containing many thousands of `UPDATE` statements, which broke Bookstack search any time someone searched for the term "update". I tracked down the timeout to the search term highlighting function, as it does not appear to have any limit to how many terms it will search for. This is understandable, as there should not be multi-thousand hit documents uploaded in this manner, but unfortunately once it happened it was not obvious where the problem was. I believe one of two options (or both) would be a good way to make this a bit more manageable. 1. Add a limit to the number of instances of a term to hightlight, maybe 20 to 30, and move on to the next document once this limit is reached. This would be rather easy to implement as an additional condition to the while statement. 2. Flag documents passing this limit, or a much higher limit, to indicate to users and admins that this particular search result has an extreme number of hits for the given search term. This is clearly much more work, both in logic and UI adjustment. https://github.com/BookStackApp/BookStack/blob/652124abaf8888339190bf2cbfd74c225ae28421/app/Search/SearchResultsFormatter.php#L85 I fully understand that this: <img width="420" height="35" alt="Image" src="https://github.com/user-attachments/assets/aceaed36-1f2e-4e65-adf3-b00b1bd99d14" /> is absolute insanity to put in a wiki page, but unfortunately people always find a way...

OVERLORD added the 🐛 Bug 🏭 Back-End labels 2026-02-05 10:05:44 +03:00

OVERLORD closed this issue

2026-02-05 10:05:44 +03:00

OVERLORD commented

2026-02-05 10:05:46 +03:00

@ssddanbrown commented on GitHub (Oct 31, 2025):

Thanks @Mikrz for reporting this, and for putting in the effort to track the cause down.
Via 1df850ea3e I've now set a limit of 25 which seems reasonable based on the previews we show, and it keeps things much more speedy. Testing has also been added to cover this scenario.

These changes will be part of the next feature release.
Thanks again!

@ssddanbrown commented on GitHub (Oct 31, 2025): Thanks @Mikrz for reporting this, and for putting in the effort to track the cause down. Via 1df850ea3ec8786444e23340566334517fa56f7a I've now set a limit of 25 which seems reasonable based on the previews we show, and it keeps things much more speedy. Testing has also been added to cover this scenario. These changes will be part of the next feature release. Thanks again!

OVERLORD referenced this issue

2026-02-05 10:34:02 +03:00

[PR #5475] [MERGED] Fix search issue for words inside Guillemets (« ») without spaces #6502

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#5475