[ 
https://issues.apache.org/jira/browse/FLINK-33444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Krishna Anandan Ganesan updated FLINK-33444:
--------------------------------------------
    Description: 
We are proposing a solution to fix potential flakiness in the following test:
{code:java}
org.apache.flink.connectors.hive.TableEnvHiveConnectorITCase#testUDTF {code}
*STEPS TO REPRODUCE THE ISSUE:*
 * The following command can be run to execute the test with the 
[NonDex|https://github.com/TestingResearchIllinois/NonDex] plugin:

{code:java}
mvn -pl flink-connectors/flink-connector-hive 
edu.illinois:nondex-maven-plugin:2.1.1:nondex 
-Dtest=org.apache.flink.connectors.hive.TableEnvHiveConnectorITCase#testUDTF
{code}

 * The following error will be encountered:

{code:java}
[ERROR] Failures: 
[ERROR]   TableEnvHiveConnectorITCase.testUDTF:270->lambda$testUDTF$5:305 
expected: "[+I[{1=a, 2=b}], +I[{3=c}]]"
 but was: "[+I[{2=b, 1=a}], +I[{3=c}]]"
[INFO] 
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped
{code}

*ROOT CAUSE ANALYSIS:*
The test is currently flaky because of the assumption that the order of 
elements received in the _results_ variable  will be consistent. There are 
currently two versions of query output that can be stored in _results_ :

# The actual order that is expected where the output of the map attribute is 
{1=a,2=b}
# The other order which is shown in the error extract above where the ordering 
of the map attribute changes to {2=b,1=a}

*POTENTIAL FIX:*
* The fix that I can suggest/have ready to raise a PR for is introducing 
another assertion on the second variant of the query output.
* By asserting whether the contents in _results_ are in one of the two orders, 
we can ascertain that the expected attributes with their contents are received 
as expected should the order in which they are received, not matter.

Please share your thoughts on this finding and let me know if any other 
potential fix is possible for this test.

 

  was:
We are proposing a solution to fix potential flakiness in the following test:
{code:java}
org.apache.flink.connectors.hive.TableEnvHiveConnectorITCase#testUDTF {code}
*STEPS TO REPRODUCE THE ISSUE:*
 * The following command can be run to execute the test with the 
[NonDex|https://github.com/TestingResearchIllinois/NonDex] plugin:

{code:java}
mvn -pl flink-connectors/flink-connector-hive 
edu.illinois:nondex-maven-plugin:2.1.1:nondex 
-Dtest=org.apache.flink.connectors.hive.TableEnvHiveConnectorITCase#testUDTF
{code}

 * The following error will be encountered:

{code:java}
[ERROR] Failures: 
[ERROR]   TableEnvHiveConnectorITCase.testUDTF:270->lambda$testUDTF$5:305 
expected: "[+I[{1=a, 2=b}], +I[{3=c}]]"
 but was: "[+I[{2=b, 1=a}], +I[{3=c}]]"
[INFO] 
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped
{code}

*ROOT CAUSE ANALYSIS:*
The test is currently flaky because of the assumption that the order of 
elements received in the _results_variable_  will be consistent. There are 
currently two versions of query output that can be stored in _results_ :

# The actual order that is expected where the output of the map attribute is 
{1=a,2=b}
# The other order which is shown in the error extract above where the ordering 
of the map attribute changes to {2=b,1=a}

*POTENTIAL FIX:*
* The fix that I can suggest/have ready to raise a PR for is introducing 
another assertion on the second variant of the query output.
* By asserting whether the contents in _results_ are in one of the two orders, 
we can ascertain that the expected attributes with their contents are received 
as expected should the order in which they are received, not matter.

Please share your thoughts on this finding and let me know if any other 
potential fix is possible for this test.

 


> Fixing the stability of 
> "org.apache.flink.connectors.hive.TableEnvHiveConnectorITCase.testUDTF"
> -----------------------------------------------------------------------------------------------
>
>                 Key: FLINK-33444
>                 URL: https://issues.apache.org/jira/browse/FLINK-33444
>             Project: Flink
>          Issue Type: Bug
>          Components: Runtime / State Backends
>            Reporter: Krishna Anandan Ganesan
>            Priority: Minor
>
> We are proposing a solution to fix potential flakiness in the following test:
> {code:java}
> org.apache.flink.connectors.hive.TableEnvHiveConnectorITCase#testUDTF {code}
> *STEPS TO REPRODUCE THE ISSUE:*
>  * The following command can be run to execute the test with the 
> [NonDex|https://github.com/TestingResearchIllinois/NonDex] plugin:
> {code:java}
> mvn -pl flink-connectors/flink-connector-hive 
> edu.illinois:nondex-maven-plugin:2.1.1:nondex 
> -Dtest=org.apache.flink.connectors.hive.TableEnvHiveConnectorITCase#testUDTF
> {code}
>  * The following error will be encountered:
> {code:java}
> [ERROR] Failures: 
> [ERROR]   TableEnvHiveConnectorITCase.testUDTF:270->lambda$testUDTF$5:305 
> expected: "[+I[{1=a, 2=b}], +I[{3=c}]]"
>  but was: "[+I[{2=b, 1=a}], +I[{3=c}]]"
> [INFO] 
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped
> {code}
> *ROOT CAUSE ANALYSIS:*
> The test is currently flaky because of the assumption that the order of 
> elements received in the _results_ variable  will be consistent. There are 
> currently two versions of query output that can be stored in _results_ :
> # The actual order that is expected where the output of the map attribute is 
> {1=a,2=b}
> # The other order which is shown in the error extract above where the 
> ordering of the map attribute changes to {2=b,1=a}
> *POTENTIAL FIX:*
> * The fix that I can suggest/have ready to raise a PR for is introducing 
> another assertion on the second variant of the query output.
> * By asserting whether the contents in _results_ are in one of the two 
> orders, we can ascertain that the expected attributes with their contents are 
> received as expected should the order in which they are received, not matter.
> Please share your thoughts on this finding and let me know if any other 
> potential fix is possible for this test.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to