The GitHub Actions job "E2E - Operation" on shardingsphere.git/fix/39537-column-offset has failed. Run started by GitHub user fudianchn (triggered by fudianchn).
Head commit for run: bb1d6c0b0c7c7661833be9d3d1f09a0e5ba58de8 / 付典 <[email protected]> Fix wrong column labels and count when metadata drifts from backend schema For queries on rule-enhanced tables, column count, names, labels and the label-index map were derived from projections expanded against ShardingSphere metadata, then paired positionally with actual backend rows. After out-of-band DDL on the backend, the metadata view drifts from the live schema and clients silently receive values attributed to wrong columns. The backend result set metadata truthfully describes the actual rows, so use the projection-derived view only when it is proven equivalent to the returned metadata: either the column counts match, or the count mismatch is fully explained by the derived columns the rewrite appends (the SUM and COUNT columns of an AVG rewrite and the derived order-by and group-by columns, appended only by a multi-route rewrite), i.e. after removing those derived columns the returned metadata still names the expanded projections. A derived alias alone is not enough, because backend schema drift and appended derived columns can occur together. Any other mismatch is genuine metadata drift, and the returned metadata is authoritative for the client-facing columns, with the derived columns hidden. QueryHeaderBuilderEngine delegates to ShardingSphereResultSetMetaData instead of duplicating the projection lookup, and StandardDatabaseProxyConnector derives the header count from the same source. COM_STMT_PREPARE derives the OK packet column count and the column definition packets from the same result, and wildcard projections, whose expansion reflects ShardingSphere metadata, are resolved through the backend probe instead of the local-metadata shortcut, so prepare metadata no longer bypasses the drift fix. The client-visible metadata decision and the visible-index mapping are computed once per ShardingSphereResultSetMetaData instance and reused by the column count, name and label accessors, so proxy query-header and MySQL prepared-statement metadata construction stays linear in the number of columns instead of repeating the returned-metadata reconciliation per accessor. When nothing can append derived columns, the client ordinal is the index of the returned metadata as-is and the column count still reads the returned metadata. Fixes #39537. Signed-off-by: 付典 <[email protected]> Report URL: https://github.com/apache/shardingsphere/actions/runs/34922545593 With regards, GitHub Actions via GitBox
