Inaccuracy in result_ttl description

[imankulov]

Here is defined that enqueue accepts and handles result_ttl option, but actually this argument should be passed to enqueue_call.

Unfortunately, it looks like the documentation sources are not available publicly, so I cannot send a pull request.

[selwin]

You're not the only one to have run into this issue. enqueue behaves differently depending on whether args or kwargs is supplied. This behavior is indeed strange and I was partly to blame as well, you can read the relevant discussion here.

So doing this wouldn't work:

q.enqueue(func=foo, result_ttl=86400)

While this would:

q.enqueue(func=foo, args=(,), result_ttl=86400)

In hindsight, I think we should have kept enqueue as it was and just introduce a new queue.q() method that cleanly separates RQ and function related arguments.

[imankulov]

Thanks for your comment, @selwin . Yes, I noticed that enqueue changes the behavior depending on presence/absence of args and kwargs, it's somewhat messy, but not that much, from my point of view.

Unfortunately, I don't quite get your point about having a queue.q(), but I make a guess. Maybe you mean something like

queue.q('foo', bar='baz').enqueue(result_ttl=ttl)
# or just
queue.q('foo', bar='baz').enqueue()

If so, as for me, it makes quite a lot of sense. It could look like subtasks in celery, and it should be very useful. It doesn't break any backward compatibility, it shouldn't be complicated to implement and it looks natural in the current set of API. Is that what you meant?

[nvie]

Actually, the sources are available publicly—but they're well-hidden on the gh-pages branch (using GitHub Pages).

But yes, your remark is correct. The example from the docs are indeed broken and need to be fixed, which I just did. Thanks.