I'm not sure what a quarantined task is. It seems to happen consistently at least for `"provisionerId": "releng-hardware", "workerType": "gecko-t-osx-1010-beta", "workerId": "t-yosemite-r7-380" as per the above example. I haven't explored other `workerId`s - but since it consistently happens for this one, that could be a good avenue to explore. You'll see the claimWork call return in less than a second, that despite making claims using that workerId, it never appears in the list of workers, and it always gets 0 tasks back, even when there are pending tasks. And since it doesn't appear in the list of quarantined workers, it isn't not getting tasks because it is quarantined. Lastly, even if it was quarantined, the connection should probably be held by the queue for 20s, but I suspect the reason it isn't is probably a symptom of the underlying bug that causes the other symptoms...
Bug 1519849 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I'm not sure what a quarantined task is. It seems to happen consistently at least for `"provisionerId": "releng-hardware", "workerType": "gecko-t-osx-1010-beta", "workerId": "t-yosemite-r7-380"` as per the above example. I haven't explored other `workerId`s - but since it consistently happens for this one, that could be a good avenue to explore. You'll see the claimWork call return in less than a second, that despite making claims using that workerId, it never appears in the list of workers, and it always gets 0 tasks back, even when there are pending tasks. And since it doesn't appear in the list of quarantined workers, it isn't not getting tasks because it is quarantined. Lastly, even if it was quarantined, the connection should probably be held by the queue for 20s, but I suspect the reason it isn't is probably a symptom of the underlying bug that causes the other symptoms...
I'm not sure what a quarantined task is. It seems to happen consistently at least for `"provisionerId": "releng-hardware", "workerType": "gecko-t-osx-1010-beta", "workerId": "t-yosemite-r7-380"` as per the above example. I haven't explored other `workerId`s - but since it consistently happens for this one, that could be a good avenue to explore. You'll see the `claimWork` call returns in less than a second, that despite making claims using that `workerId`, it never appears in the list of workers, and it always gets 0 tasks back, even when there are pending tasks. And since it doesn't appear in the list of quarantined workers, it isn't not getting tasks because it is quarantined. Lastly, even if it was quarantined, the connection should probably be held by the queue for 20s, but I suspect the reason it isn't is probably a symptom of the underlying bug that causes the other symptoms...