There is no way to get job.id before processing

[dinana]

In Kue, you can listen to enqueue events and the job.id will be populated, in Kue-scheduler this event is not fired, even if I job.save(), it will fire only the first time I run, on second run of the app it will not fire (Check line #696 in job.js in Kue, the state is 'inactive' only on first-run).

Also, the 'schedule success' event supplies job without the id.

[dinana]

In fact, if I supply a done function to every/now/schedule it will get a job object with id populated.

[dinana]

This is in fact not correct, they still don't get the id, apologies for the confusion.

[lykmapipo]

Hello. Please may you add a spec/test for this that will fail.

On 2 Oct 2016 21:09, "dinana" notifications@github.com wrote:

This is in fact not correct, they still don't get the id, apologies for the confusion.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lykmapipo/kue-scheduler/issues/55#issuecomment-250985625, or mute the thread https://github.com/notifications/unsubscribe-auth/ABiUaQeHLCf1woWV3qBEQbufi8ujTOM7ks5qv_NXgaJpZM4KL_p7 .

[dinana]

This should work in every.spec.js:

it('should be able to get job.id after scheduling', function(done) {
      var data = {
        to: faker.internet.email()
      };

      var backoff = {
        delay: 60000,
        type: 'fixed'
      };

      var job = Queue
        .createJob('unique_every', data)
        .attempts(3)
        .backoff(backoff)
        .priority('normal')
        .unique('every_mail');

      Queue.every('2 seconds', job, function(err, job) {
        expect(job.id).to.exist;
        done();
      });
    });

The reason being that unlike .schedule and .now, .every does not save the job until the job key is expired then you save it, which is basically how you're able to pull off repeating tasks. However, this along with #53 makes sharing data between repeating jobs impossible.

[lykmapipo]

@dinana For every kue-scheduler use the provided job as a definition. It does not save the job right away until it next run. The actual job occur when the work is performed.

You can use kue Queue events

Unless there is a specific use case you have.

[dinana]

In definition time, I need to keep track of the jobs to be able to reference them again for more fine-grained control, the problem here is that the job only gets saved on first run, and is untraceable before that.

[lykmapipo]

@dinana We will see how we can achieve this in future version.