meteor-job-collection icon indicating copy to clipboard operation
meteor-job-collection copied to clipboard

Correct way to check if job is cancelled?

Open gitTerebi opened this issue 9 years ago • 5 comments

While processing job, how do I check if it has been cancelled?

At the moment I do

if (!job.progress(0, 100)) { cb(); return; }

But when I look at the console log is full of W20150908-13:28:27.867(10)? (STDERR) jobProgress failed

I thought I could do a job.status === 'cancelled' (or something like that) but the status field isn't actually updated.

gitTerebi avatar Sep 08 '15 03:09 gitTerebi

I assume in your code above is running on a Meteor server (with Fibers). If not, then your job.progress() call needs a callback to get the result.

If the result isn't true, then the progress update failed. It may be because the job isn't running (cancelled, failed, done), or it may be because the job has been removed (no longer exists). If the job still exists on the server, you can update the job object by calling job.refresh(), If that is successful, then you can inspect job.doc.status to see why the job is no longer running.

vsivsi avatar Sep 08 '15 04:09 vsivsi

Thanks,

I was cancelling and them immediately removing the job from the server, causing the console.warn

I created utility method, that checks if job is still in collection before calling the progress method.

gitTerebi avatar Sep 08 '15 04:09 gitTerebi

Hi, you can do that, but it necessarily creates a race condition, right? It seems that you still need to handle the rare case where the job is removed between the two calls, which is the same case you are trying to handle by creating the method in the first place...

vsivsi avatar Sep 08 '15 04:09 vsivsi

Good point, all this to avoid console.warn

However i'm happy to leave the rare case as it removes most of the console messages.

Because of the cancel -> remove there is always going to be a race condition really.

gitTerebi avatar Sep 08 '15 05:09 gitTerebi

I've been considering for some time to put all of the remaining console.warns under some kind of "debug mode". I don't want to remove them, because they are useful at times, but yes they often fire for expected behavior, which junks up the console. Let me think about it tomorrow.

vsivsi avatar Sep 08 '15 05:09 vsivsi