When marking several entries as read, the unread count for affected feeds is updated in a background job.

With commit 843739263910629ec48b4d4469f73a146a7358bf this should make changing entries state much faster than before. As soon as all entries in the feed/folder/all have been marked as read (which is done with a single SQL UPDATE) jobs are queued to update the unread count for affected feeds (enqueuing jobs in Resque is relatively unexpensive) and immediately the response for the client is returned.

This means that the response to the user is not delayed while the new unread entries counts for feeds are calculated. They are calculated in the background while the control is returned to the user as soon as possible.

This means that if the user refreshes the page immediately after clicking on "mark all as read" button, he may see some feeds with a non-zero unread count. This shouldn't be a big problem; some time later the corresponding job will run and the correct unread count will be set, and if the user clicks on such a feed he will get no entries and the count will immediately become zero. A bit surprising perhaps but not a big deal.

Also this happens only if the user immediately refreshes the page; if he doesn't refresh the page he will not be aware that the recalculation of the counts happens some time later, because the angularjs running in the view sets the correct numbers as soon as the button is clicked.