Regrettably, not much we can do here - the ABORTED status, in some cases, doesn't get set until the Pipeline finishes executing, so we can't tell from Declarative that we should be treating the build as ABORTED.

abayer, rather than just saying this won't be fixed, perhaps it is better to remove features that provide the illusion that `ABORTED` is a supported state that can be handled in declarative pipelines? Then there will be no confusion

(I suspect this issue will continue to be reported when someone else tries to handle `aborted` in a `post` block)

The thing is that ABORTED does work in some contexts, but not others. It's weird.

abayer I've observed the following:

When running parallel steps with fastFail set, the fast-failed aborted build will return FAILURE if the act of aborting a step that was still in progress returns an error code. 

However if other parallel steps have finished successfully, and the last running step fails, this correctly returns ABORTED in the event of failure.

Some kind of race condition where if a step fails, fastFail aborts all other steps, and the last error code returned is the status seen by the declarative pipeline, but isn't the one respected by the overall build.status? Hopefully that makes sense. 

Is there not a reliable way to get from the rawBuild if a build was aborted?
I cannot image that there's no way - as the builds are eventually - when they are totally finished - always displayed with the right result. 'Only' currentBuild.currentResult is very often giving a different result (FAILURE usually)
We're using this hack now to get better detection of aborted builds:

if (currentBuild.rawBuild.getActions(jenkins.model.InterruptedBuildAction.class).isEmpty()) {
   return currentBuild.currentResult
} else {
  return "ABORTED"
}

Bulk closing resolved issues.

Thanks kutzi – this workaround is indeed very helpful! (Of course one would prefer a proper/clean solution/fix... )

reinholdfuereder according to your comment, you still have experienced this issue in the current release?
I'm having the workaround in place and therefore not watching it anymore.
According to Liam's comment this should have been fixed?

Jenkins 2.375.1, manually aborted build had `currentBuild.currentResult`= success, sending notification as such. Workaround helped.