Strange behaviour with Scripted assertions in JDBC Requests

Hello,

I have a test case with 8 steps - Data source, Groovy script, SOAP request, Delay, Groovy script, JDBC request1, JDBC Request2 and Data source loop. In each of the JDBC requests, I have a scripted assertion. I have a strange issue. If in any iteration, if the scripted assertion in any of the JDBC requests fail, In the next iteration, the same test step is marked as Failed though there is no issue and the assertions also pass. The later iterations are fine. If test step 6 fails in iteration 4, the same test step again fails in iteration 5 though all the assertions pass.

Following are the scripted assertions in my JDBC Requests.

Assertion in JDBC Request 1 -

import com.eviware.soapui.support.XmlHolder

def holder = new XmlHolder( messageExchange.responseContentAsXml )
def totalRows = holder.getNodeValue('//Results/ResultSet/Row/TOTALROWS')
def expectedResult = context.expand( '${GetDataForGM#ExpectedResult}' )
def messageID = context.expand( '${JDBC_Request1#messageID}' )

if (expectedResult == "Pass") {
 assert totalRows.toInteger() >= 1
}
else if (expectedResult == "Fail"){
 assert totalRows.toInteger() == 0
} 

Assertion in JDBC Request 2 -

import com.eviware.soapui.support.XmlHolder

def holder = new XmlHolder( messageExchange.responseContentAsXml )
def totalRows = holder.getNodeValue('//Results/ResultSet/Row/TOTALROWS')
def expectedResult = context.expand( '${GetDataForGM#ExpectedResult}' )
def messageID = context.expand( '${JDBC_Request2#messageID}' )

if (expectedResult == "Pass"){
 assert totalRows.toInteger() == 0
}
else if (expectedResult == "Fail") {
 assert totalRows.toInteger() >= 1;
} 

Also wanted to add - This is very random and happens most of the times.
sometimes, if I make changes to the scripted assertions like adding a log statement or changing the else if to if statement, it works fine but resurfaces after some time. does this have anything with the cache? Once this issue occurs, it occurs even if I exit soapui Pro and get back in.