I have a pipeline script job with this script:

properties([
        buildDiscarder(logRotator(numToKeepStr: '5')),
    ]
)

def c = {
    node(null) {
        def sb = new StringBuilder()
        sb.append('<testsuite>')
        def bn = (env.BUILD_NUMBER.toInteger() % 3) + 1
        def sets = []
        for (int i = 0; i < 20; ++i) {
            sets.add('S' + i)
        }
        sets.each { set ->
            for (int i = 0; i < 200; ++i) {
                if (i % bn == 0) {
                    sb.append("<testcase time=\"2.6875\" classname=\"${set}.SomeLongLongLongLongLongTestName_${i}\" name=\"Run 0\" assertions=\"3 total, 0 failed, 3 succeeded\">")
                    sb.append("<failure message=\"failure message ${i}\" type=\"Failure\"/>")
                    sb.append("</testcase>")
                } else {
                    sb.append("<testcase time=\"2.6875\" classname=\"${set}.SomeLongLongLongLongLongTestName_${i}\" name=\"Run 0\" assertions=\"3 total, 0 failed, 3 succeeded\"/>")
                }
            }
        }
        sb.append('</testsuite>')
        writeFile file: 'result.xml', text: sb.toString()
        junit testResults: 'result.xml'
    }
}
parallel 'p1': c, 'p2': c

int buildNumber = env.BUILD_NUMBER as int
if (buildNumber > 5) {
    error 'Intentionally failing this build'
}

//throw new Exception() // Most builds fail for us, but still produce partial but meaningful result, uncomment this to cause failure

Run it a few times, it produces test results based on our day to day scenario. The results will be displayed in the Test Result Trend on the job page. Now, uncomment that last line to cause it to fail and then delete all successful or unstable builds (e.g. through job rotation). The test result graph disappears and does not appear unless I comment that line again and produce at least one non-failed build.

I have no idea why Jenkins does this or where this logic is, thus the assignment to 'core' could be wrong. In any case, perhaps this logic made sense in the past, but for scripted pipeline it doesn't. One can control the result of the build programmatically. Plus, a build can contain many steps, thus any graphs should be shown regardless of the final job status. This is especially true in a complex parallel stage scenario, where a single stage can produce an exception.

For us this issue is critical, because the test trend is not working, so we can't get an overview, and accessing the test history takes a long time in our scenario with thousands of builds.

I went through echarts and JUnit plugins, replacing all the checks and fiddling around, but it seems that the root cause is somewhere else. From my understanding, floatingBox.jelly is not loaded at a higher level just based on the build status, potentially preventing multiple plugins from working in this scenario.