What

qkindFromMysqlType (the binary binlog / QRep type-conversion path) mapped MySQL BIT to Int64, while QkindFromMysqlColumnType (the information_schema / DDL text path) already mapped it to UInt64. This made BIT columns that flow through the binary path inconsistent with the rest of the system.

The binary path is reached for:

• columns discovered via TABLE_MAP_EVENT without a captured DDL event (e.g. gh-ost / online-schema-change migrations) — processTableMapEventSchema
• the QRep watermark column type
• the QRecordSchemaFromMysqlFields fallback for columns absent from the table schema

A plain ALTER TABLE ... ADD COLUMN bit(...) is not affected — it's captured as a DDL query event and already routes through the UInt64 text path.

Change

• Map BIT to UInt64 in qkindFromMysqlType, gated behind a new InternalVersion_MySQLConvertBitToUInt64.
• Thread the mirror version through qkindFromMysqlType / QRecordSchemaFromMysqlFields and their callers (CDC, QRep, e2e helper).
• Add a unit test covering the version gate.

Why gate it

The destination column type is fixed when a column is first created. An existing mirror that already materialized a BIT column as Int64 via the binary path would break if the code started emitting UInt64 values into that Int64 column on upgrade (schema deltas add columns, they don't retype existing ones). Gating on InternalVersion keeps existing mirrors on their previous behavior and gives only new mirrors the consistent UInt64 mapping.

Testing

• New unit test TestQkindFromMysqlType_Bit asserts Int64 below the gate version and UInt64 at/above it.
• go build ./... and the connectors/mysql unit tests pass.

Note: a normal full-table BIT e2e test does not exercise this path, since in-schema BIT columns resolve their type via the ungated text path. The meaningful behavioral difference is limited to the gh-ost/TABLE_MAP_EVENT-detected-column and QRep cases described above.

🤖 Generated with Claude Code