Fix Job.schedule() not rescheduling after cancel()

[laeubi]

The aboutToRunCanceled flag was not being cleared when reschedule=true, causing jobs to be canceled instead of scheduled. This fix moves the flag clearing to after the early returns, ensuring it's always cleared when actually scheduling the job.

Test verifies that Job.schedule() works correctly after cancel() when called on a running job. This reproduces the issue where the aboutToRunCanceled flag was not being cleared during reschedule.

FYI @basilevs

Maybe we can build on this?

[github-actions]

Test Results

 1 947 files  ±0   1 947 suites  ±0   2h 0m 41s ⏱️ + 8m 49s
 4 722 tests +1   4 695 ✅  - 1   24 💤 ±0  3 ❌ +2 
14 166 runs  +3  13 990 ✅  - 5  167 💤 ±0  9 ❌ +8 

For more details on these failures, see this check.

Results for commit 3943cdf. ± Comparison against base commit 70d775d.

♻️ This comment has been updated with latest results.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

runtime/bundles/org.eclipse.core.jobs/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 84af0bc38178c71e3211dfbc7829190bd8c8803e Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Thu, 23 Oct 2025 10:26:13 +0000
Subject: [PATCH] Version bump(s) for 4.38 stream


diff --git a/runtime/bundles/org.eclipse.core.jobs/META-INF/MANIFEST.MF b/runtime/bundles/org.eclipse.core.jobs/META-INF/MANIFEST.MF
index 1991fbccb9..be708b1eea 100644
--- a/runtime/bundles/org.eclipse.core.jobs/META-INF/MANIFEST.MF
+++ b/runtime/bundles/org.eclipse.core.jobs/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.core.jobs; singleton:=true
-Bundle-Version: 3.15.700.qualifier
+Bundle-Version: 3.15.800.qualifier
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
 Export-Package: org.eclipse.core.internal.jobs;x-internal:=true,
-- 
2.51.0

Further information are available in Common Build Issues - Missing version increments.

[basilevs]

@iloveeclipse has pointed out, that job seems to start despite getState() we will have to reevaluate, what are we fixing here and why.

I had to create #2210 formulated in terms of Job.join() instead. Job.join() turns out to have no guarantees because it is documented in terms of Job.getState() internal API, which provides no guarantees or contracts.

Therefore the solution might be to fix Javadoc for Job.join() to indicate, that it has no contract, or invent one and adapt Job.join() to follow it.

[basilevs]

This is not enough to reproduce a problem with getState() returning spurious Job.NONE. Why has this test failed in the first place?

[basilevs]

I've managed to apply this delta and org.eclipse.core.tests.runtime.jobs.Bug_550738.testCancelSchedule() has started to fail. Does Copilot run any tests?