Obtain Failure chain in ProcessModelPostStepFailure callback

[owziga]

Hi,

I am using the Teststand 2022 and I want to save the calling stack of the step that caused the sequence failure as well as all of the parameters of the adapter at the time of failure to display them in the fail banner.

I have managed to do it in the model post step failure, with the following code (I omit the part from the parameters): 

Basically in the PreMainSequence I empty the FileGlobals.SequenceFailureMessage, and in the PostStepFailure I store all the data in a local variable and at the end of the loop I store it in FileGlobals.SequenceFailureMessage to latter display them with a modified modelsupport2.dll.

The issue is that I sometimes the call stack that I display does not match the failure chain in the report.

I believe is because an step of the subsequence fails, but the subsequence is run in a pass fail count loop and manages to pass at the end, as I have already saved the failure call stack (SequenceFailureMessage it's not empty) I do not save it.

If I save the call stack independently if the SequenceFailureMessage is empty or not, sometimes it does not match the failure chain in the report as it displays the first step that failed rather than the last one.

I have tried checking the Status of the step caller and even if it is the last try of the loop it returns "Running" and CausedSequenceFailure/SequenceFailed is set to false.

Is there a way to check if the current failure is the one that caused the test failure?

The only solution that comes to mind is saving all the failures in an array and at the end obtain the ID of the step through the critical failure stack to know which call stack display, but with the new plugins model the critical failure stack is not populated when the display fail banner is called (as it was for example with the Teststand 4.2)

Thank you in advance.

[Scott_Richardson]

Configuring a step to loop sets an expression that determines whether the overall status of the step should pass or fail. That condition is stored on the loop step's properties under Step.TS.LoopStatus. For a simple loop of 10 times and the step fails on every call, the step failure callback is called 10 times, and then it is called again when the step evaluates the loop status and it evaluates to False (Failed), so a total of 11.

In my test that fails every step call, the value of RunState.Caller.RunState.SequenceFailed is False for the first 10 calls to the callback and is True for the 11th call where the step is evaluating the loop status. You should be able to just look at that property.

Note that for subsequent steps that fail in the sequence with the looping step, that property will still be True, so you have to only process when on the first call to the callback per call stack.