Posted over 11 years ago. Visible to the public. Repeats.

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 Unpoly Archive , up.observe() Archive or up.autosubmit() Archive will do this for you.
  • If you make the request yourself you may also choose to abort an earlier XHR request Archive . You may also abort fetch() requests Archive .

Your development team has a full backlog of feature requests, chores and refactoring coupled with deadlines? We are familiar with that. With our "DevOps as a Service" offering, we support developer teams with infrastructure and operations expertise.

Owner of this card:

Henning Koch
Last edit:
about 2 years ago
by Henning Koch
live, search, race, condition, serialize, debounce
About this deck:
We are makandra and do test-driven, agile Ruby on Rails software development.
License for source code
Posted by Henning Koch to makandra dev
This website uses short-lived cookies to improve usability.
Accept or learn more