[Bugfix]Adding conditions to longer matching entries in conditional marks

[yutongzhang-microsoft]

Description of PR

As part of #11968, a bugfix was introduced in the find_longest_matches function to identify only the longest matching entry in tests_mark_conditions.yaml.

The previous bug led to incorrect behavior in finding the matching entries, deviating from our intended logic before:

• Our expected behavior was to retrieve only the longest matching entry and evaluate the conditions under this single, unique entry.
• Instead, the bug caused the function to retrieve all entries matching the test case prefix, evaluating conditions from all matching entries.
  This resulted in an unintended situation where conditions from shorter matching entries which are absent in the longest one would still be considered during evaluation.

In PR #14395, we optimized the logic for finding marks in conditional marking. Now, although we will retrieve all entries matching the test case prefix but only the longest matching entry is evaluated if the mark is identical across all matching entries, which aligns with our original expectations. Additionally, conditions that exist only in shorter matching entries with the same mark are now ignored. To maintain consistency with previous behavior(although unexpected), we have added these conditions to the longer matching entry.

Summary:
Fixes # (issue)

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• Test case(new/improvement)

Back port request

• 202012
• 202205
• 202305
• 202311
• 202405

Approach

What is the motivation for this PR?

As part of #11968, a bugfix was introduced in the find_longest_matches function to identify only the longest matching entry in tests_mark_conditions.yaml.

The previous bug led to incorrect behavior in finding the matching entries, deviating from our intended logic before:

• Our expected behavior was to retrieve only the longest matching entry and evaluate the conditions under this single, unique entry.
• Instead, the bug caused the function to retrieve all entries matching the test case prefix, evaluating conditions from all matching entries.
  This resulted in an unintended situation where conditions from shorter matching entries which are absent in the longest one would still be considered during evaluation.

In PR #14395, we optimized the logic for finding marks in conditional marking. Now, although we will retrieve all entries matching the test case prefix but only the longest matching entry is evaluated if the mark is identical across all matching entries, which aligns with our original expectations. Additionally, conditions that exist only in shorter matching entries with the same mark are now ignored. To maintain consistency with previous behavior(although unexpected), we have added these conditions to the longer matching entry.

How did you do it?

To maintain consistency with previous behavior(although unexpected), we have added these conditions to the longer matching entry.

How did you verify/test it?

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

[ZhaohuiS]

#11968 was reverted in 202405 #14912
So we still need to use length = len(list(condition.keys())[0])
instead of "length = len(list(condition.keys())[0])" ?
And the solution is to update conditional mark yml file and add all conditions for one case, right?

[yutongzhang-microsoft]

#11968 was reverted in 202405 #14912 So we still need to use length = len(list(condition.keys())[0]) instead of "length = len(list(condition.keys())[0])" ? And the solution is to update conditional mark yml file and add all conditions for one case, right?

Hi, @ZhaohuiS, we have new logic in conditional mark in #14395 which will cherry pick into 202405 soon. Yes, this is the solution

[mssonicbld]

@yutongzhang-microsoft PR conflicts with 202311 branch

[mssonicbld]

@yutongzhang-microsoft PR conflicts with 202405 branch

[mssonicbld]

@yutongzhang-microsoft PR conflicts with 202305 branch

[mssonicbld]

@yutongzhang-microsoft PR conflicts with 202205 branch

[mssonicbld]

@yutongzhang-microsoft PR conflicts with 202012 branch

[mssonicbld]

@yutongzhang-microsoft PR conflicts with 202405 branch