getStatus just reports a threadName. It should also indicate whether task had been created, and whether it is considered cancelled or done.
In principle a call to stop after start but before the task starts running could result in a hung step. This would normally be a very short interval, though, since the thread pool is unbounded. Could be made more robust.
Originally reported by 
jglick, imported from: Strengthen SynchronousNonBlockingStepExecution.getStatus
- status: Open
- priority: Minor
- component(s): workflow-step-api-plugin
- label(s): diagnostics, robustness
- resolution: Unresolved
- votes: 1
- watchers: 2
- imported: 20260601-173816
Raw content of original issue
getStatus just reports a threadName. It should also indicate whether task had been created, and whether it is considered cancelled or done.
In principle a call to stop after start but before the task starts running could result in a hung step. This would normally be a very short interval, though, since the thread pool is unbounded. Could be made more robust.
getStatus just reports a threadName. It should also indicate whether task had been created, and whether it is considered cancelled or done.
In principle a call to stop after start but before the task starts running could result in a hung step. This would normally be a very short interval, though, since the thread pool is unbounded. Could be made more robust.
Originally reported by
jglick, imported from: Strengthen SynchronousNonBlockingStepExecution.getStatus
Raw content of original issue