Selwin Ong

> It's not a very usable solution, as count is used as a property, and it's also used when doing len so it's very difficult to prevent developers to trigger...

I think implementing `get_job_count()` would be simpler, let's do that first and see if that fixes your issue.

There's a [branch](https://github.com/selwin/rq/blob/ce731bd35fbcb6634065472f635f86b57ff1403f/rq/registry.py) containing a job `Registry` class that maintains a list of enqueued jobs (and their functions). Once this is merged in, we'll be able to do: ``` python...

Not at the moment. You'd have to extend it by getting all jobs having that function (a cheap operation) and checking for their arguments (may be expensive depending on the...

@VidJa this feature is not yet implemented. This is something I look forward to tackling when I have the time. The first step would be to build a mapping of...

We don't have an API for this at the moment. I'd accept a PR for `result.expire_at()` or `result.expire_in()` to change result TTL.

Actually I just realized something, the cleaning timestamp has to be done on a per queue basis and not RQ wide. It could be that we have different workers working...

> Unless I did it wrong, my changes store the cleaning timestamp per worker and the cleaning will be done on all the queues of this worker. It's not a...

> If I have 10 workers running rq worker high and 1 worker running rq worker low, all the workers will store their last maintenance timestamp at the same rq:workers:last_cleaned_at...

Agreed, we already have a `contrib` module and the newer Sentry integration already lives there. Further cleanups are welcome :)