strange interactions between last_cleaned_at, maintenance_interval and rq:clean_registries lock key about rq HOT 1 OPEN

However if the worker just started, last_cleaned_at is None and should_run_maintenance_tasks returns True immediately. This could cause should_run_maintenance_tasks to return True too quickly if workers are short-lived
👉 Why not store last_cleaned_at as a redis key with the worker id as prefix?

I stored this as a local worker attribute so we can eliminate an extra Redis call everytime this is checked (if you have many short lived jobs, workers will perform an extra Redis call everytime they finish). But I think your suggestion is correct, we can also add a Redis key that's shared across all workers.

the maintenance task runs the clean_registries method which takes a lock on queues. However the lock is implemented in a strange way, it's a simple redis key rq:clean_registries:%s with a TTL of 899, but it's never deleted. So the clean_registries cannot run more often than 899 sec, even if the maintenance_interval is smaller
👉 Why not delete the lock once the maintenance task has been done?

The lock should be deleted once maintenance task is finished. Mind opening a PR for this?

from rq.