Mike Parent

I ran into this problem with the Redis broker, as the priorities only apply to pre-fetched tasks pulled down on an individual worker. There might be a way to get...

@kastman - Yes, a doc change would be quite helpful (perhaps pointing to separate queues as a Redis workaround), as I spent a bit of time determining that Redis backend...

We started seeing this exact issue recently with both 1.8 and 1.9, after initially running without any problems for several months. I suspect it's related to worker reloads re-enqueing messages....

It occurs on every deployment (stop workers, start new workers), usually 1-10 minutes after the new workers start up, and only 1 new worker has the error each time, then...

Hi @santigandolfo, I ultimately ended up adding automatic retries inside our tasks (via `urllib3.util.retry.Retry` adaptor for 3rd-party APIs), and ended up not using the workaround above, as this simple approach...

Yeah, that's a good suggestion @ccurvey. Would require catching any exceptions that did not derive from `Retry` (ex: third-party library errors), and re-raising some sort of `Retry`-derived exception, but that...

Wanted to add my 👍 for these changes, using similar with our own 3.10 stack

@mezhaka - I've been using this workaround -- ``` import re import pytest from requests_toolbelt.multipart import decoder from vcr.matchers import _get_transformer, _identity from vcr.util import read_body def decode_multipart_request_body(request): return decoder.MultipartDecoder(...