Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Job uniqueness #167

Closed
JokerQyou opened this issue Jan 27, 2020 · 2 comments
Closed

Job uniqueness #167

JokerQyou opened this issue Jan 27, 2020 · 2 comments
Labels
docs Need an edit to the documentation.

Comments

@JokerQyou
Copy link

JokerQyou commented Jan 27, 2020

The doc says:

arq supports this via custom job ids, see see arq.connections.ArqRedis.enqueue_job(). It guarantees that a job with a particular ID cannot be enqueued again until its execution has finished.

Which seems to imply that once a job has finished its execution, a new job with the same ID can be enqueued. But this is not true. If the job has result (return value, traceback information, etc.) left in Redis, new job with the same ID cannot be enqueued, see these lines of code. In this case the value of keep_result when initialize the worker would affect time duration of this conflict.

I think it's better to mention this in the Job uniqueness section.

@samuelcolvin
Copy link
Member

yes true, happy to accept a PR to correct this in the docs.

@samuelcolvin samuelcolvin added the docs Need an edit to the documentation. label Apr 24, 2021
@JonasKs
Copy link
Collaborator

JonasKs commented Apr 5, 2023

Closed by #391

@JonasKs JonasKs closed this as completed Apr 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Need an edit to the documentation.
Projects
None yet
Development

No branches or pull requests

3 participants