Problem
On databases carrying the dolthub/dolt#11131 class of storage drift (TEXT/LONGTEXT columns ALTERed under a pre-2.1 Dolt: row bytes left un-rewritten), the aux row re-key crashes the whole migration pass mid-way.
The re-key (bd-6dnrw.2 lineage) scans every column of events/comments/issue_snapshots/compaction_snapshots. Decoding one of the affected cells makes the Dolt server panic and drop the connection:
Error 1105 (HY000): panic recovered: invalid hash length: 19
github.com/dolthub/dolt/go/store/val.AdaptiveValue.convertToTextStorage
github.com/dolthub/dolt/go/store/val.(*TupleDesc).GetStringAdaptiveValue
The migration pass dies between cursor updates, leaving a dirty working set; subsequent passes hit the dirty-table gates. On our single shared sql-server (~140 databases, 28 with drifted tables) this blocked a fleet-wide migration drain until patched.
The underlying storage defect is dolt-side — we reported our variant as dolthub/dolt#11205 (follow-up to #11131, filed at @timsehn's request); affected cells are not even repairable from SQL (UPDATE/DELETE of the bad rows panic the same way). So bd cannot assume the data can be fixed first: the migration path itself has to survive these tables.
Fix we ship on our fork (offer to PR)
767d5dcdef: the re-key detects the panic signature per table, logs a loud warning, skips that table and continues the pass. Migrations complete; the skipped table keeps its old per-clone row ids.
Rationale for skip-over-fail: on a shared single sql-server the cross-clone PK convergence the re-key provides is moot for that table anyway, while a crashed migration pass takes the whole database out of upgradability. The warning keeps the skip visible to operators.
Given this week's bd-578h9 hardening series touches the same pass, happy to send the PR rebased on current main — or adapt the detection (it keys on the invalid hash length panic substring) to whatever shape you prefer.
Problem
On databases carrying the dolthub/dolt#11131 class of storage drift (TEXT/LONGTEXT columns ALTERed under a pre-2.1 Dolt: row bytes left un-rewritten), the aux row re-key crashes the whole migration pass mid-way.
The re-key (bd-6dnrw.2 lineage) scans every column of
events/comments/issue_snapshots/compaction_snapshots. Decoding one of the affected cells makes the Dolt server panic and drop the connection:The migration pass dies between cursor updates, leaving a dirty working set; subsequent passes hit the dirty-table gates. On our single shared sql-server (~140 databases, 28 with drifted tables) this blocked a fleet-wide migration drain until patched.
The underlying storage defect is dolt-side — we reported our variant as dolthub/dolt#11205 (follow-up to #11131, filed at @timsehn's request); affected cells are not even repairable from SQL (
UPDATE/DELETEof the bad rows panic the same way). So bd cannot assume the data can be fixed first: the migration path itself has to survive these tables.Fix we ship on our fork (offer to PR)
767d5dcdef: the re-key detects the panic signature per table, logs a loud warning, skips that table and continues the pass. Migrations complete; the skipped table keeps its old per-clone row ids.Rationale for skip-over-fail: on a shared single sql-server the cross-clone PK convergence the re-key provides is moot for that table anyway, while a crashed migration pass takes the whole database out of upgradability. The warning keeps the skip visible to operators.
Given this week's bd-578h9 hardening series touches the same pass, happy to send the PR rebased on current main — or adapt the detection (it keys on the
invalid hash lengthpanic substring) to whatever shape you prefer.