Comment 18 for bug 2003851

The important point to note is that fetchAfter==0 is the default case if we did not get retries, so every non-retried item has that value and we don't want to cycle it. The loop's purpose is to find the smallest timeout to wait for, as an _optimization_ to the select() call below, such that if we have an item queued to fetch in 5s we fetch it in 5s even if we received no updates from the workers to process.

The queue is ordered such that all the 0 fetchAfter items come first (so as not to get stuck behind FetchAfter ones), but there may be an issue there since new owners of items can appear that can *change* the fetch after after we have inserted the item, it probably needs to be dequeued and requeued when an owner is added (or when we change FetchAfter of an owner, but I think we do there already).