-
Notifications
You must be signed in to change notification settings - Fork 47
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
kue-scheduler does not Save unique data until first run of job. #79
Comments
@gmcnaught This is because In case of two job with the same unique constraint am planning to move on using Hope we can work on this to improve documentation and implementing the desired feature. |
I solved this on my end by looking for the existence of the data object
before creating a unique job in a wrapper of kue-scheduler, it was just an
unexpected behavior for the unique job lookup to not exist after every, but
on save.
…On Mon, Feb 6, 2017 at 4:15 AM, lally elias ***@***.***> wrote:
@gmcnaught <https://github.com/gmcnaught> This is because kue-scheduler
rely much on redis working to achieve what it does in scheduling every
jobs. So if you say a job to run every five seconds it will wait until
five second for it to create a job.
In case of two job with the same unique constraint am planning to move on
using redis data structure that fit for the work than just a stringified
objects.
Hope we can work on this to improve documentation and implementing the
desired feature.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#79 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABTsf1lWW0edCdvg8Nh4vJk60nS2ybeMks5rZuS4gaJpZM4LwbfH>
.
|
I was wrapping a pre-check for an existing job with the same unique name when I noticed a behavior I think I understand the reason for:
If you create a job:
So I noticed this, and I'm not sure how to fix it, but it does to at least be documented - as I was struggling with why if I looked in q:unique:jobs, the job would not exist until it is scheduled for the first time, but I see now that save does not get called until the first scheduled run of the job.
This creates an opportunity where you could create two jobs with the same unique constraint and it would depend on which job was scheduled last(?) which job would win in being the 'unique' job, correct?
The text was updated successfully, but these errors were encountered: