Add a warning for misconfiguration.

[icfly2]

As specified in the docs, by default the settings result in a configuration where slow tasks that run for more than 60s cause repeated running of tasks, which has caused a few issues. This warning doesn't change the defaults, which would be a marge larger change, but instead provides a, hopefully, helpful message to the user.

This has caused issues before: #183 and others.

And it confused me, and only careful reading of the docs reveals this.

[Koed00]

Thanks for fixing that. After fixing typo, I will merge and put it in the next release

[jonaswinkler]

Just came here to let you know that this warning is also raised with the default configuration (timeout=None, retry=60), which works perfectly fine with redis, even with long running tasks.

[Koed00]

I didn't spot that earlier. I guess we can take out the check for TIMEOUT to be not None.

[icfly2]

I haven’t tested this with a redis backend but from the docs it implies that timeout = None would lead to never timing out for all backends and then this problem should persist. If it doesn’t, maybe exclude redis and other backends where this issue doesn’t occur.

Just came here to let you know that this warning is also raised with the default configuration (timeout=None, retry=60), which works perfectly fine with redis, even with long running tasks.

Yes the default leads to problems with long running tasks, thus the warning also in default. Can you confirm that a task that takes longer than 60 seconds does not get called repeatedly with a redis backend?

[jonaswinkler]

Can you confirm that a task that takes longer than 60 seconds does not get called repeatedly with a redis backend?

I can confirm that even with 'retry=1', no long running tasks get repeated at all. As expected, since the documentation states this option won't have any effect with brokers that don't support delivery receipts, and redis is one of those.

Also, the system check framework would probably be a much better tool to implement checks like this one.

[icfly2]

Just checked the docs and as far as I can see only Redis doesn't support delivery receipts. I guess the nicest way to do this would be to check for the attribute / function that is used for delivery receipts, else a list of brokers could be fine and the assumption that if you are using a custom broker you know what you are doing.

[markopy]

I get this warning as well with the latest version. I'm setting timeout=None explicitly and I don't want any retries to happen (using ack_failures=True). It seems there is no combination of settings which avoids the warning for this use case. retry cannot be set to None either.

[icfly2]

@markopy What backend are you using?

[markopy]

@icfly2 I use the orm backend in this case. I think for my case the issue is also that (aside from setting ack_failures=True) there is no real way to actually disable retries so setting timeout=None basically never makes sense unless the backend doesn't support delivery receipts. Which seems to be only Redis.

I have resolved this issue by simply setting timeout and retry to very large numbers. I think the documentation and default settings are misleading here. timeout should never be None unless you are doing something very specific.