I can reproduce this again on both our Jenkins instances: with Build-Step 2.12 and Pipeline Groovy 2.80.

Here is a minimal example: The second part of the "unstable -> success"  stage is never executed.

// Parent Job
node(){
    def stage_map = [:]
    stage_map['success'] = trigger('SUCCESS')
    stage_map['unstable -> success']= {trigger('UNSTABLE').call(); trigger('SUCCESS').call()} // The second SUCCESS step is never triggered
    
    parallel(stage_map)
}

def trigger(status){
    return {
        def result = build job:
            'test_child',
            parameters: [
                    string(name: 'status', value: status)
                ]
    }
}

// Child Job
node(){
      properties([
        parameters([string(name: 'status', defaultValue: 'SUCCESS')])
    ]) 
    currentBuild.result = params.status
}

The second part of the "unstable -> success" stage is never executed.

As designed. Your parent job should terminate at that point with an UNSTABLE status. This change does not make the build step complete normally; it just makes the exception thrown indicate to the Pipeline machinery that (if uncaught) the build should have the indicated status. If you do not want that, then use propagate: false as before.

Thanks for clearing that up.

This fix introduced a new bug in my pipeline.

The `build` step used to throw hudson.AbortException, but was changed to org.jenkinsci.plugins.workflow.steps.FlowInterruptedException.

The problem: AbortException had a "message" which contained the job name/number, along with its status. We used this in our error handling to include context to the error. FlowInterruptedException contains no message, so our error handling fails. Unless I'm missing something, it contains almost no information on what actually failed.

Should this bug be re-opened, or a new bug opened to pass FlowInterruptedException some contextual information?

EDIT: Here's a code snippet to help explain:

try{
    def results = build job: 'fooJob'
    def job_number = results.getNumber()
} catch (e) {
    // AbortMessage included a message along the lines of...
    // "fooJob #13 completed with status FAILURE (propagate: false to ignore)"
    // We used this message to add context to the error
    def msg = e.getMessage() // Sadly, this is null for FlowInterruptedException
}

Should this bug be re-opened

As a general rule: no, not unless the originally described bug was not in fact fixed. If a change causes some undesirable behavior, file a separate bug with a Link to the original.

In this case there is no bug, your script was simply relying on undocumented behavior. The FlowInterruptedException does include all the same information, just in a DownstreamFailureCause rather than the Throwable.message.

Anyway using a catch block and the exception here was the wrong idiom even before this change. Set propagate: false and inspect the resulting build object’s status and other fields.