Right now many unit tests are racy because the jobs involve shelling out to run date or a similar command, and there is no way for the scheduler of a job to know when that job has actually completed, so we rely on time.Sleep() and similar mechanisms.
This tends to create a problem for small time.Sleep() values or when running tests with -count # for testing durability.
A likely solution would be to add something like context.Done() to job.Job wherein the caller gets a channel which can be read from to block execution until the job completes.
Note: the behavior is not racey, but the tests are in some cases.
Right now many unit tests are racy because the jobs involve shelling out to run
dateor a similar command, and there is no way for the scheduler of a job to know when that job has actually completed, so we rely ontime.Sleep()and similar mechanisms.This tends to create a problem for small
time.Sleep()values or when running tests with-count #for testing durability.A likely solution would be to add something like
context.Done()tojob.Jobwherein the caller gets a channel which can be read from to block execution until the job completes.Note: the behavior is not racey, but the tests are in some cases.