Separate BatchJobDeregister evals updates #4744
Conversation
Fixes hashicorp#4299 There is a race between job purging and job-deregister evaluations handling that seem to cause completed jobs to re-run unexpectedly when they are being GCed. Here, we make `BatchDeregister` behave just like `Deregister`, where we submit the `job-deregister` evals after `JobBatchDeregisterRequest` is committed to raft.
| } | ||
|
|
||
| // Populate the reply with job information | ||
| reply.Index = index |
There was a problem hiding this comment.
not sure if this is actually needed but followed the pattern in Dispatch - I guess it's somewhat relevant if we exit early if we hit an error below - but I'm unsure of the ramifications. Are Dispatch or BatchDispatch expected to be atomic operations?
| ID: uuid.Generate(), | ||
| Namespace: jobNS.Namespace, | ||
| Priority: priority, | ||
| Type: jtype, |
There was a problem hiding this comment.
Noticed that previous code sets priority and type from the job - but Deregister method doesn't. Should we do that there as well?
|
Will using a different approach to fix the bug. Closing and opening a new PR shortly. |
|
I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
Fixes #4299
There is a race between job purging and job-deregister evaluations
handling that seem to cause completed jobs to re-run unexpectedly when
they are being GCed.
Here, we make
BatchDeregisterbehave just likeDeregister, where wesubmit the
job-deregisterevals afterJobBatchDeregisterRequestiscommitted to raft.
Open Questions: