Release 3.9.0

What's new in release 3.9.0

To work with check1 3.9.0 you need to install the grpc-check1 library with version 3.5.1 or higher.

New features

Silence check after CheckSequence rule and NoMessageCheck rule

There are some cases when you expect some messages sequence to be received and nothing more matches key fields in that sequence is received after that.
In the previous check1 version, there was no such functionality.
The release 3.9.0 introduces two ways of doing that:

• Automated silence check after CheckSequence rule;
• NoMessageCheck rule for manual verification.

Silence check

This functionality adds verification that no more messages that match the pre-filter in the CheckSequence rule
was received after the rule main CheckSequence rule is completed.
The timeout for which the silence check awaits the messages is either the cleanup timeout (cleanup-older-than + cleanup-time-unit) is exceeded
or the next rule has been submitted to the chain.
You can enable it per request by silence_check parameter.

from google.protobuf import wrappers_pb2 as wrappers

CheckSequenceRuleRequest(
  # ...
  silence_check=wrappers.BoolValue(value=True) # or False, or you might not set silence_check at all
)

import com.exactpro.th2.check1.grpc.CheckSequenceRuleRequest;

CheckSequenceRuleRequest.newBuilder()
    .setSilenceCheck(BoolValue.of(true)) // or false, or you might not set silenceCheck at all

If it is not set the silence check will be added automatically if the auto-silence-check-after-sequence-rule in check1 configuration is enabled.

NoMessagesCheck rule

This rule allows you to check that no messages that match the specified filter were received during a certain time period.
It is very similar to the silence check but can be used independently.
The timeout for the rule might be specified based on real-time or messages time.

Timeout for rules based on the message's time

The current version of check1 allows you to specify the timeout that is based on real-time.
When a user specifies the small timeout to make sure that messages were received quickly enough it might cause unexpected rule failure.
It happens because check1 processes messages with a different speed depending on the load and resources.
And in some cases, the message you need to verify might be received by check1 but not yet processed.

Here comes the message_timeout parameter. It allows you to specify the timeout based on the messages' timestamps.
Please note, that using message_timeout requires either a checkpoint or an existing chain_id.
They are required to compute borders for message timestamp.
You can specify a small message_timeout and a bigger timeout to allow check1 process messages.
When it sees the message with a timestamp that exceeds the computed borders it completes the rule.

Default timeout

There is a new rule-execution-timeout parameter that allows you to specify the default timeout
for rule execution if the request does not contain one.
It allows you to specify only the message_timeout in the request.

Precision for comparing numbers and date-time values

The new version of check1 allows you to use precision for comparing numbers and date-time values.
To get the advantage of comparison with the precision you should use EQ_TIME_PRECISION or EQ_DECIMAL_PRECISION operation
depending on the value type you try to compare.
There are default precisions for those operations. They can be specified using time-precision and decimal-precision parameters in check1 configuration.
Also, you can specify the precision per filter. The RootComparisonSettings now has two parameters:

• time_precision - is used to specify the precision for comparing date-time values (please note, that they should be represented in ISO format)
  Examples:

  import datetime
  
  td = datetime.timedelta(days=3, minutes=10)
  duration = Duration()
  duration.FromTimedelta(td)
  RootComparisonSettings(
    # other parameters
    time_precision=duration
  )

  import com.exactpro.th2.common.grpc.RootComparisonSettings;
  import com.google.protobuf.util.Durations;
  
  RootComparisonSettings.newBuilder()
    .setTimePrecision(Durations.fromMillis(100))
    .build();

• decimal_precision - is used to specify the precision for comparing numbers. Can be in engineering format and the regular one (e.g. 125E-3 or 0.125)

Null value filter

Now you can assert that the message contains some field with null value (the field presents in the message but it has a value of null).
NOTE: only EQUAL and NOT_EQUAL operations are supported.

Example:

ValueFilter(
  operation=FilterOperation.EQUAL,
  null_value=NullValue
)

import com.exactpro.th2.common.grpc.ValueFilter;
import com.exactpro.th2.common.grpc.NullValue;

ValueFilter.newBuilder()
    .setOperation(FilterOperation.EQUAL)
    .setNullValue(NullValue.NULL_VALUE)
    .build();

Changes

Consider null value in a message as empty

The default behavior regarding null values in a message has been changed in check1.
If the field presents in the message and has the value null the EMPTY filter won't pass anymore.
The opposite for NOT_EMPTY. It will pass in case the field exists but has a null value.
If you want to enable the old behavior you can switch it using check-null-value-as-empty parameter in the check1 configuration.

Failure reason improvements

When you specify the filter and the actual message has that field but the content type is different (you expected the simple value but a sub-message was received in the message)
the old version of check1 did not say anything useful and just marked the field as failed.
Also, when something happened during field comparison there was no information about what has happened.
Starting with version 3.9.0 the hint is added in these cases. You will see in the UI a message that explains what has happened.
NOTE: this improvement will work only with a report-viewer version 3.1.95 or higher.

Displaying null and string values in verification

The previous version of check1 did not separate the null value and the string "null".
It might cause a misunderstanding of the verification result. Version 3.9.0 reports the values regarding the actual value.

NOTE: this improvement will work only with a report-viewer version 3.1.102 or higher.

Fixes

failUnexpected parameter was not propagated to sub-messages

There was a problem when you specify the failUnxpected parameter but fields in sub-messages (or collections of messages)
does not cause a failure. That was happening because the parameter's value was not propagated to the sub-messages.

Incorrect matching of repeating groups

There was a problem with matching repeating groups when the filter contains fewer elements than the actual message
and they are received in a different order. In this case, check1 might match the incorrect elements and the verification result might confuse users.