Problem

Job.schedule() would randomly fail to reschedule a job after cancel() was called, leaving the job in NONE state instead of properly scheduling it. This manifested as a timing-sensitive bug where jobs would simply stop executing after a cancel/schedule sequence.

Root Cause

The issue occurred in JobManager.scheduleInternal() when the following sequence of events happened:

1. A job is running
2. User calls cancel() → sets aboutToRunCanceled = true (to prevent the job from starting if not yet running)
3. User calls schedule() → since job is still running, marks it for reschedule but doesn't clear the flag
4. Job finishes and endJob() calls scheduleInternal(job, delay, reschedule=true)
5. Bug: The aboutToRunCanceled flag was only cleared when reschedule=false
6. doSchedule() sees the flag is still true and cancels the job instead of scheduling it

The condition if (!reschedule) before clearing the flag prevented proper rescheduling in this scenario.

Solution

The fix moves the job.setAboutToRunCanceled(false) call to execute after the early returns (when job is already running or not in NONE state) and before actually scheduling the job. This ensures:

• The flag is cleared only when we're actually going to schedule the job
• Any explicit schedule() call overrides any previous cancel() call
• The flag doesn't persist incorrectly across scheduling attempts

// Before: conditional clearing
if (!reschedule) {
    job.setAboutToRunCanceled(false);
}

// After: unconditional clearing when actually scheduling
if (job.getState() == Job.RUNNING) {
    return false; // early return
}
if (job.internalGetState() != Job.NONE) {
    return false; // early return
}
job.setAboutToRunCanceled(false); // always clear before scheduling

Testing

Added regression test Bug_550738.testCancelThenScheduleWhileRunning() that reliably reproduces the issue:

• Runs 100 iterations to catch the timing-sensitive bug
• Each iteration: starts a job, calls cancel(), immediately calls schedule(), and verifies the job reschedules correctly

Without the fix, this test fails when the job incorrectly stays in NONE state. With the fix, it passes consistently.

Impact

• No breaking changes - only fixes incorrect behavior
• Thread-safe - change is within existing synchronized block
• Minimal - only 7 lines changed in production code
• Related issues: Fixes Job.schedule() randomly sometimes not rescheduling eclipse-platform/eclipse.platform#160, related to Bug 550738 and Bug 574883

Closes eclipse-platform#160

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.