The outcome of the report happens to be incorrect in 2 scenarios.

Classic jobs

Scenario:

1. A project is created with FailedThreshold/unstableThreshold set to 1 because there's 1 test expected to fail in the next run
2. Job N starts executing, execution time will take minutes
3. FailedThreshold/unstableThreshold gets adjusted to 0 because the test is expected to pass in the next run
4. Job N terminates: the execution is then reported as UNSTABLE instead of the expected SUCCESS by the xUnit publisher, which wrongly uses the adjusted threshold (0) instead of the one configured at startup (1)

Pipeline job

Scenario:

1. A parallel section is defined with 2 test steps (A and B), each one with FailedThreshold/unstableThreshold set to 0
2. test step A will generate 1 test failure
3. test step B will generate 0 test failure
4. test steps starts in parallel
5. test step A terminates with 1 test failure: the execution is correctly reported as UNSTABLE
6. test step B terminates with 0 test failure: the execution is wrongly reported as UNSTABLE
   When test step B terminates before test step A, that's the other way around: test step B is correctly reported as SUCCESS, then test step A is wrongly reported as SUCCESS.