Make 01565_query_loop_after_client_error slightly more robust

CI founds one failure of this test [1], which is quite interesting, the
test itself should not takes too long:

    2023.06.04 05:01:36.889144 [ 42287 ] {} <Trace> DynamicQueryHandler: Request URI: /?query=SELECT+%27Running+test+stateless%2F01565_query_loop_after_client_error.expect+from+pid%3D1053%27&database=system&connect_timeout=30&receive_timeout=30&send_timeout=30&http_connection_timeout=30&http_receive_timeout=30&http_send_timeout=30&output_format_parallel_formatting=0
    ...
    2023.06.04 05:01:37.364595 [ 42844 ] {fa79939f-1fa0-4f3b-b599-fd2269122d6a} <Debug> executeQuery: (from [::1]:40264) (comment: 01565_query_loop_after_client_error.expect) INSERT INTO t01565(c0, c1) VALUES  (stage: Complete)
    2023.06.04 05:01:37.366485 [ 42844 ] {fa79939f-1fa0-4f3b-b599-fd2269122d6a} <Information> TCPHandler: Change cancellation status from NOT_CANCELLED to FULLY_CANCELLED. Log message: Received 'Cancel' packet from the client, canceling the query.
    2023.06.04 05:01:37.366810 [ 42844 ] {fa79939f-1fa0-4f3b-b599-fd2269122d6a} <Debug> TCPHandler: Processed in 0.002539914 sec.

But for the last INSERT the client itself works **very slow**, which
seems was the reason why "\r" had been sent too early and was never
interpreted:

    send: sending "INSERT INTO t01565(c0, c1) VALUES ('1', 1) ;\n" to { exp4 }

    expect: does " " (spawn_id exp4) match glob pattern "INSERT"? no
    I
    expect: does " \u001b[21GI\u001b[0m\u001b[J\u001b[22G" (spawn_id exp4) match glob pattern "INSERT"? no
    
    expect: does " \u001b[21GI\u001b[0m\u001b[J\u001b[22G\u001b[21G" (spawn_id exp4) match glob pattern "INSERT"? no
    INSERT INTO t
    expect: does " \u001b[21GI\u001b[0m\u001b[J\u001b[22G\u001b[21GINSERT INTO t\u001b[0m" (spawn_id exp4) match glob pattern "INSERT"? yes
    expect: set expect_out(0,string) "INSERT"
    expect: set expect_out(spawn_id) "exp4"
    expect: set expect_out(buffer) " \u001b[21GI\u001b[0m\u001b[J\u001b[22G\u001b[21GINSERT"
    send: sending "\r" to { exp4 }

    expect: does " INTO t\u001b[0m" (spawn_id exp4) match glob pattern "Ok."? no
    
    expect: does " INTO t\u001b[0m\u001b[J" (spawn_id exp4) match glob pattern "Ok."? no
    
    expect: does " INTO t\u001b[0m\u001b[J\u001b[34G" (spawn_id exp4) match glob pattern "Ok."? no
    
    expect: does " INTO t\u001b[0m\u001b[J\u001b[34G\u001b[21G" (spawn_id exp4) match glob pattern "Ok."? no
    INSERT INTO t01565(c0, c1) VALUES ('1', 1) ;

    
    expect: does " INTO t\u001b[0m\u001b[J\u001b[34G\u001b[21G\u001b[JINSERT INTO t01565\u001b[0;22;33m(\u001b[0mc0\u001b[0;1m,\u001b[0m c1\u001b[0;22;33m)\u001b[0m VALUES \u001b[0;22;33m(\u001b[0;22;36m'1'\u001b[0;1m,\u001b[0m \u001b[0;22;32m1\u001b[0;22;33m)\u001b[0m \u001b[0;1m;\u001b[0m\r\n\r\n\u001b[0m\u001b[1G" (spawn_id exp4) match glob pattern "Ok."? no
    expect: timed out

Here you can see that it matched "INSERT" and then expect receive data
from the client almost byte by byte.

So I hope that expecting the last part of the query should fix the
problem.

  [1]: https://s3.amazonaws.com/clickhouse-test-reports/50429/228ebab86db95dca1e29967061d245985bc86a0f/stateless_tests__release__s3_storage__[2_2].html
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
This commit is contained in:
Azat Khuzhin 2023-06-04 10:58:05 +02:00
parent f1eba08eaf
commit 60c2245da4

View File

@ -24,24 +24,24 @@ expect "\n:) "
send -- "DROP TABLE IF EXISTS t01565;\n"
# NOTE: this is important for -mn mode, you should send "\r" only after reading echoed command
expect "DROP"
expect "\r\n"
send -- "\r"
expect "\nOk."
expect "\n:)"
send -- "CREATE TABLE t01565 (c0 String, c1 Int32) ENGINE = Memory() ;\n"
expect "CREATE"
expect "\r\n"
send -- "\r"
expect "\nOk."
expect "\n:) "
send -- "INSERT INTO t01565(c0, c1) VALUES (\"1\",1) ;\n"
expect "INSERT"
expect "\r\n"
send -- "\r"
expect "\n:) "
send -- "INSERT INTO t01565(c0, c1) VALUES ('1', 1) ;\n"
expect "INSERT"
expect "\r\n"
send -- "\r"
expect "\nOk."
expect "\n:) "