-
Notifications
You must be signed in to change notification settings - Fork 109
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
Latest release breaks Hangfire #153
Comments
No, not tried the latest, but the merge contains nothing new. |
I'm not sure I follow, it looks like a lot of changes from 1.9.3. I strongly suggest delisting the latest NuGet package!
I mean once the job starts processing, it doesn't finish it once all of the code has run. Additionally it looks like parallelization may be broken? Please, give it a try and you'll see what I'm talking about. |
Sure, it contains changes from 1.9.5 and the two PR about job requeiung and changes for uniforming async use. But ok, unlisting it's the safest option here.
I'll do for sure. |
I can confirm that a job is being requeued after being succesfully executed, in an apparently infinite loop. Didn't spot anything about parallelization. |
It turns out that the problems arise with: @Lexy2 Can you shed a light on that flag ? |
It seems that at least
|
I'll take a look. For now I think the best way is to delist the package, revert #152 and publish a version without this particular change. |
Yeah, it's completely busted. I wonder how this happened, I'll take a look tomorrow. |
…b fetchedJob). Seems to to address #153 but further investigatios needed.
I believe Hangfire modifies its behavior if the storage indicates support for RemoveFromQueue. It seems to depend on IWriteOnlyTransaction.RemoveFromQueue to dequeue a job once it is completed. I've just implemented this method with:
It appears to process the jobs correctly, but further tests and documentation are required for this function. I plan to release a pre-release version, 1.10.1-Beta1, to facilitate testing. |
I wonder the same, I was sure the code was already running before the lasts merges and this problem predates it. As you're at it, would you please check my last two commits on |
The jobs stay fetched, so it's not yet complete :-( |
True. It appears it depends because of line 63 of RedisFetchedJob, the condition returns false.
Do you remember why this check was added ? |
Yes, this check is actually a fix for #135. Hangfire orders the storage to remove the timed out job, and storage should only do this if it's the same job (and not its requeued copy). |
Wouldn't it be easier just to remove the capability from the storage so that Hangfire would use the other methods? |
I don't know what the |
Yuck. I'll try to find time to look into it. Still don't understand why it worked then and does not now. |
Okay, so I added this As for jobs not being removed from dequeued state, this seems to be a recent change from Hangfire. Change in behaviour. I'm reviewing changes to Hangfire core to see if I can spot the issue. |
Not sure if you guys have tried the new version, but we had to revert to 1.9.3 because it would not complete jobs.
Related to this work: #150
The text was updated successfully, but these errors were encountered: