The issue involves the quick search feature in Discourse causing multiple search requests for each typed character, leading to 403 errors, particularly when unregistered users are involved. Canapin reports that this occurs after selecting the “in this category” option and typing, with the problem appearing more frequent on meta.discourse.org and try.discourse.org but not on personal instances. Canapin notes that while the error hasn’t occurred recently, it may be related to rate limits. sam has prioritized investigating this due to potential unnecessary traffic. pmusaraj clarifies that the search widget debounces requests every 400ms, so rapid typing avoids multiple requests, and demonstrates that only two requests were sent between specific inputs, indicating the behavior depends on typing speed.
Reproduction steps:
It seems to happen more when unregistered, maybe because of a different rate limit.
Notes: It doesn’t happen if you write the #categoryname manually, and after you delete your search query input to perform another search.
The bug is still here, I see all the requests in the network tab, but I haven’t experienced the error message for a while. Were the max requests per second increased for users?
Also, it’s to be noted that while this bug happens on meta.discourse.org and try.discourse.org, it doesn’t happen on my instances.
Perhaps is it related to some setting?
will put a pri-medium on investigating, cause this has potential of driving too much traffic, unnecessarily.
It depends on the typing speed. If you type fast enough, the request won’t be sent for each keystroke. The widget debounces sending the request every 400 milliseconds, if user types below that threshold, the request won’t be sent. Tested on Safari/Firefox/Chrome on macOS, it works well on each.
You can see this as proof:
It only sent two requests between typing “Customization > Theme component data” and “Customization > Theme component data expl”, i.e. no requests for the characters in between.