morningman opened a new pull request, #67789:
URL: https://github.com/apache/doris/pull/67789

   ### What problem does this PR solve?
   
   Problem Summary:
   
   Nothing in the tree asserts the bytes a MySQL client actually receives, or 
the Arrow batches an
   Arrow Flight SQL client actually receives. Every test around the frontend's 
result path stops at the
   `QueryState` or at a `ShowResultSet`; the packet framing below that -- how 
many packets, in what
   order, with which sequence ids, terminated by an EOF or an OK, flushed where 
-- is only exercised by
   real clients in the regression suites, and only for the handful of 
statements those suites run.
   
   That gap is about to matter. The session and result layers are being 
reorganized so that MySQL and
   Arrow Flight SQL become two front ends over one session (the follow-up PRs 
extract a protocol
   adapter and a result sender out of `ConnectContext`, `ConnectProcessor` and 
`StmtExecutor`). Those
   are pure refactors, and a pure refactor that drops an EOF packet, reorders a 
column definition, or
   shifts a sequence id passes every existing unit test and shows up only as a 
client that hangs.
   
   This PR takes the baseline first, before anything moves. It adds no 
production code.
   
   ### What is changed?
   
   Four test classes under 
`fe/fe-core/src/test/java/org/apache/doris/qe/protocol/` and two golden
   files under `fe/fe-core/src/test/resources/protocol-golden/`:
   
   - `RecordingMysqlChannel` -- a `DummyMysqlChannel` that plays canned request 
packets and records
     every response packet: its payload, the sequence id it was framed with, 
and whether the response
     was flushed at it. The sequence id is advanced the way the real channel 
advances it (once per
     packet read, once per packet written), so what is recorded is what would 
reach the wire.
   - `ProtocolGolden` -- renders the recorded traffic as an annotated hexdump 
and compares it with the
     checked-in file. On a mismatch it writes the current traffic to 
`target/protocol-golden/<name>`
     and names it in the failure message, the same convention 
`AccessControlBehaviorBaselineTest` uses.
   - `MysqlPacketGoldenTest` -- 27 cases: constant selects, a NULL literal, an 
empty result set,
     `SHOW VARIABLES`, `DESC` (the one case whose row stream is longer than a 
single packet), `SET`,
     `USE`, `EXPLAIN`, a syntax error, an unknown table, an error followed by a 
healthy statement on the
     same connection, multi-statement requests with and without 
`CLIENT_MULTI_STATEMENTS`, and the
     connection commands (`COM_FIELD_LIST`, `COM_STMT_PREPARE`, 
`COM_STMT_CLOSE`, `COM_SET_OPTION`,
     `COM_RESET_CONNECTION`, `COM_PING`, `COM_INIT_DB`, `COM_STATISTICS`, an 
unknown command,
     `COM_QUIT`). Two of them run with `CLIENT_DEPRECATE_EOF` negotiated off, 
the capability that
     decides whether a result set ends in an EOF or an OK and whether the 
column definitions get their
     own terminator.
   - `FlightResultGoldenTest` -- the same statements an Arrow Flight SQL 
session can be answered
     frontend-side, recorded as the schema and rows of the `VectorSchemaRoot` 
the session caches, or as
     the error it failed with.
   
   Capability negotiation is replayed rather than mocked: the test derives the 
effective capability the
   way `MysqlProto.negotiate()` does (`server & client`) and sets 
`clientDeprecatedEOF`,
   `clientMultiStatements` and the serializer capability from it, so the 
recorded packets match what a
   real connection with those flags would produce.
   
   Two responses are recorded as shape rather than bytes, because their payload 
legitimately moves with
   changes that have nothing to do with the protocol: a parser error carries 
the entire keyword list of
   the grammar (4881 bytes today), and an `EXPLAIN` carries the current plan 
text. For those the golden
   keeps the packet kinds, plus the error code, SQL state and the start of the 
message.
   
   The statement set is limited to what a frontend answers on its own. 
`COM_STMT_EXECUTE` is
   deliberately absent: `ConnectContext.supportHandleByFe()` is false for it, 
so its result always comes
   from a backend and belongs in `prepared_stmt_p0`, not here. No case in 
either test reaches a backend
   (verified: the mocked backend logs no `exec_plan_fragment` request during 
the run).
   
   The two golden files are added to `.licenserc.yaml`'s `paths-ignore`: both 
tests regenerate the file
   in full and compare it byte for byte, so a license header would be read back 
as unexpected content.
   
   ### Release note
   
   None.
   
   ### Check List (For Author)
   
   - Test
       - [x] Unit Test
       - [ ] Regression test
       - [ ] Manual test (add detailed scripts or steps below)
       - [ ] No need to test or manual test. Explain why:
   
   - Behavior changed:
       - [x] No.
       - [ ] Yes.
   
   - Does this need documentation?
       - [x] No.
       - [ ] Yes.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to