Concurrency issues with find-as-you-type boxes
Find-as-you-type boxes are usually built by observing changes in a text field, and querying the server via AJAX for search results or suggestions when the field has changed.
A common problem with this implementation is that there is no guarantee that AJAX responses are evaluated in the same order as the original requests. The effect for the user is that the search results are flashing back and forth while the user is typing the query, and when the user has stopped typing the last results don't always match the final query.
You won't notice this effect while developing on a local development server like Webrick, which processes requests one at a time. You will however notice the effect after deploying on a production server with multiple concurrent worker processes. Consider using Passenger in development instead.
- An dirty solution for small applications is to make the observe frequency low enough that out-of-order responses become unlikely enough. Try to poll the query field for changes every 0.75 seconds or longer. It will still fail when the server is busy or on flakey connections.
- A cleaner solution would be to check whether a response contains the matches for the most recent request, and discard all other responses.
- Or have a client-side queue so you don't send multiple requests at the same time. If you're using , or will do this for you.
- If you make the request yourself you may also choose to . You may also .
Flaky tests are tests that sometimes fail for no obvious reason. They are the plague of many end-to-end (E2E) test suites that automate the browser through tools like Capybara and Selenium.
Join our free training event and learn to fix any flaky test suite, even in large legacy applications.