[BUG] Deleting a queue leaves behind processed counts

[tschaub]

Describe the bug After deleting a queue, I expected Redis keys associated with that queue to be deleted. It looks like the processed counts are left behind, so when a new queue is created with the same name, it starts with the old processed counts.

To Reproduce

1. Process some tasks using the default queue
2. inspector.DeleteQueue("default", true)
3. See keys like asynq:{default}:processed and asynq:{default}:processed:2022-07-06 left behind.

Expected behavior After using the inspector to delete a queue, I expected that data associated with that queue would be removed. When I later created a new queue with the same name (default), I expected the processed count (e.g. visible in the dashboard) to be zero. Instead, I found that the new queue started with the old count of processed tasks.

Environment:

• macOS 12.4
• github.com/hibiken/asynq v0.23.0

I'm not sure if this is a bug or user error. If there is another way to clean up after processing, I can help make that clearer in the documentation.

[tschaub]

I'm guessing that something like https://github.com/tschaub/asynq/commit/88dedc243838176abc17e9628125a957e5ef1583 could be the start of a fix. It looks like the existing test doesn't result in any processed tasks, so it doesn't really serve as a regression test.

[hibiken]

@tschaub Thank you for reporting this bug! Please feel free to open a PR if you are willing to work on it (Please assign the issue to yourself, if you're working on it) If not, I can get to it in a couple of weeks.

[SaltySooda]

for asynq:{default}:processed , I add ProcessedTotalKey.but for asynq:{default}:processed:2022-07-06,I don't know how to get time param for ProcessedKey please check #514