unstable test testEvaluatorSuite.TestExprOnlyPushDownToFlash

[zhouqiang-cl]

Bug Report

[2021-06-20T02:17:33.559Z] FAIL: expr_to_pb_test.go:906: testEvaluatorSuite.TestExprOnlyPushDownToFlash

[2021-06-20T02:17:33.559Z] 

[2021-06-20T02:17:33.559Z] expr_to_pb_test.go:950:

[2021-06-20T02:17:33.559Z]     c.Assert(canPush, Equals, true)

[2021-06-20T02:17:33.559Z] ... obtained bool = false

[2021-06-20T02:17:33.559Z] ... expected bool = true

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

in ci https://ci.pingcap.net/blue/organizations/jenkins/tidb-unit-test-nightly/detail/tidb-unit-test-nightly/1296/pipeline

2. What did you expect to see? (Required)

3. What did you see instead (Required)

4. What is your TiDB version? (Required)

master 712fb1c

[wshwsh12]

/cc @LittleFall

[LittleFall]

/assign

[lzmhhh123]

@LittleFall Any updates?

[LittleFall]

investigating

[LittleFall]

The root cause: the current version of TiDB server will add the date_add function to the blacklist when it bootstraps, so that the push down of this function is blocked. Even though the test suite initialization of TestExprOnlyPushDownToFlash does not execute this bootstrap process, it may still be initialized by other tests that are executed concurrently.

Another evidence is that the test TestExprPushDownToFlash is similar to TestExprOnlyPushDownToFlash, but it has no test for date_add and is very stable.

[ti-srebot]

Please edit this comment or add a new comment to complete the following information

Not a bug

1. Remove the 'type/bug' label
2. Add notes to indicate why it is not a bug

Duplicate bug

1. Add the 'type/duplicate' label
2. Add the link to the original bug

Bug

Note: Make Sure that 'component', and 'severity' labels are added
Example for how to fill out the template: #20100

1. Root Cause Analysis (RCA) (optional)

2. Symptom (optional)

3. All Trigger Conditions (optional)

4. Workaround (optional)

5. Affected versions

6. Fixed versions

[tisonkun]

@LittleFall do you know which commit introduce the blacklist logic for that expression? I'm curious why we do not detect the violation at the first place.

[LittleFall]

@LittleFall do you know which commit introduce the blacklist logic for that expression? I'm curious why we do not detect the violation at the first place.

blame this line you can get it's this pr