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

Synchronous job management API #499

Open
LostKobrakai opened this issue Feb 24, 2022 · 1 comment
Open

Synchronous job management API #499

LostKobrakai opened this issue Feb 24, 2022 · 1 comment

Comments

@LostKobrakai
Copy link
Contributor

I'm testing that my application adds jobs to quantum correctly based on some business restrictions and I'm using on_exit to remove jobs again after tests. This however is causing issues with the ecto sandbox, because even after calling Scheduler.delete_job the job has not been removed and jobs access the db even after being supposed to be removed. Currently I need to add a timeout here to delay my on_exit callback. While working on said feature I had similar issues with run_job, which also is async.

It would be great if the async nature of those job APIs would be highlighted in the docs and I'd really like to see options to have those operations be done synchronous as well.

@maennchen
Copy link
Member

maennchen commented Feb 24, 2022

@LostKobrakai Yes, all jobs are managed async.

For the docs, a PR is very welcome.

I'm thinking about how we could block management calls like add / delete etc. Since this whole thing is based on GenStage and information flows towards the end of the chain, blocking until everything is fully removed is quite hard. Especially since the executor could be behind in time and working on a backlog of executions.

I'm generally open to discussing possible solutions to this, but I don't see an easy solution to this and will for sure not have time to implement it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants