-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-35328: [Go][FlightSQL] Fix flaky test for FlightSql driver #38044
Conversation
|
After merging your PR, Conbench analyzed the 5 benchmarking runs that have been run so far on merge-commit 1cad7a7. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 7 possible false positives for unstable benchmarks that are known to sometimes produce them. |
…pache#38044) ### Rationale for this change Fixing a flaky test that is *very* difficult to reproduce. ### What changes are included in this PR? Adding an explicit call to drain the remaining batches from the parameter batch reader in the `DoPutPreparedStatementQuery` of the `MockServer` in the tests. This ensures that the gRPC connection doesn't close on us in between the client writing the schema message and writing the record batch message producing an `io.EOF` error. This is an extremely rare occurence based on goroutine scheduling due to the client and mockserver both running in the same process for the tests, in local testing i was only able to get it to happen 1 - 4 times per 5000 runs of the test. ### Are there any user-facing changes? No * Closes: apache#35328 Authored-by: Matt Topol <zotthewizard@gmail.com> Signed-off-by: Matt Topol <zotthewizard@gmail.com>
…pache#38044) ### Rationale for this change Fixing a flaky test that is *very* difficult to reproduce. ### What changes are included in this PR? Adding an explicit call to drain the remaining batches from the parameter batch reader in the `DoPutPreparedStatementQuery` of the `MockServer` in the tests. This ensures that the gRPC connection doesn't close on us in between the client writing the schema message and writing the record batch message producing an `io.EOF` error. This is an extremely rare occurence based on goroutine scheduling due to the client and mockserver both running in the same process for the tests, in local testing i was only able to get it to happen 1 - 4 times per 5000 runs of the test. ### Are there any user-facing changes? No * Closes: apache#35328 Authored-by: Matt Topol <zotthewizard@gmail.com> Signed-off-by: Matt Topol <zotthewizard@gmail.com>
…pache#38044) ### Rationale for this change Fixing a flaky test that is *very* difficult to reproduce. ### What changes are included in this PR? Adding an explicit call to drain the remaining batches from the parameter batch reader in the `DoPutPreparedStatementQuery` of the `MockServer` in the tests. This ensures that the gRPC connection doesn't close on us in between the client writing the schema message and writing the record batch message producing an `io.EOF` error. This is an extremely rare occurence based on goroutine scheduling due to the client and mockserver both running in the same process for the tests, in local testing i was only able to get it to happen 1 - 4 times per 5000 runs of the test. ### Are there any user-facing changes? No * Closes: apache#35328 Authored-by: Matt Topol <zotthewizard@gmail.com> Signed-off-by: Matt Topol <zotthewizard@gmail.com>
Rationale for this change
Fixing a flaky test that is very difficult to reproduce.
What changes are included in this PR?
Adding an explicit call to drain the remaining batches from the parameter batch reader in the
DoPutPreparedStatementQuery
of theMockServer
in the tests. This ensures that the gRPC connection doesn't close on us in between the client writing the schema message and writing the record batch message producing anio.EOF
error. This is an extremely rare occurence based on goroutine scheduling due to the client and mockserver both running in the same process for the tests, in local testing i was only able to get it to happen 1 - 4 times per 5000 runs of the test.Are there any user-facing changes?
No