fix: size bigint unsigned as numeric(20,0); commit table migration tx - #279
Open
Danish-sarwar1 wants to merge 1 commit into
Open
fix: size bigint unsigned as numeric(20,0); commit table migration tx#279Danish-sarwar1 wants to merge 1 commit into
Danish-sarwar1 wants to merge 1 commit into
Conversation
MySQL BIGINT UNSIGNED columns propagate no source column length, so the redshift type defaulted to numeric(18,0). Values above 10^18-1 (e.g. the int64-max sentinel 9223372036854775807) fail COPY with "Overflow for NUMERIC(18,0)" and the loader retries the batch forever. Size such columns to numeric(20,0), which holds the full unsigned 64-bit range. Explicitly propagated lengths are respected. Also fix migrateTable: when redshiftGroup was set, it returned right after GrantSchemaAccess and skipped tx.Commit(), silently rolling back the whole table migration. The type widening above relies on this migration path committing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
💤 Files with no reviewable changes (1)
WalkthroughChangesRedshift type sizing
Schema access formatting
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem 1: BIGINT UNSIGNED overflows NUMERIC(18,0)
MySQL
BIGINT UNSIGNEDmaps tonumeric(redshift.gomysql type map), and since BIGINT columns propagate no__debezium.source.column.length,applyLengthfalls back to the default precision →numeric(18,0)(max ~10¹⁸).Production impact:
wallet_transactions.quantityrows carry the int64-max sentinel9223372036854775807(9.2×10¹⁸). Redshift COPY fails:and the loader retries the same batch forever — both reach-campaign sinks were stalled on this.
Fix: when
sourceColType == "bigint unsigned"and no length is propagated, size the column asnumeric(20,0)— the full unsigned 64-bit range (max 18446744073709551615 = 20 digits). Explicitly propagated lengths are still respected; masked columns are unaffected (stillcharacter varying(50)).Migration note: existing tables with bigint-unsigned columns currently at
numeric(18,0)will schema-migrate (viaReplaceTable) once on their next load after this rolls out — that is the intended path for wideningwallet_transactions.Problem 2: migrateTable never committed when redshiftGroup is set
load_processor.gomigrateTable()had a strayreturn err(err = nil) afterGrantSchemaAccess, beforetx.Commit()— so for any sink withredshiftGroupconfigured, the whole table migration (ReplaceTable + grant) was silently rolled back while reporting success. Removed the early return so the transaction falls through to commit.This matters here because the numeric widening above is applied by that migration path.
Tests
Extended the
GetRedshiftDataTypetable: bigint-unsigned default →numeric(20,0), explicit length respected (numeric(22,0)), masked →character varying(50).gofmt,go vet, fullgo test ./cmd/... ./pkg/...pass in the CI image.Related: #277 (zero-padding fix for the parallel date-format incident). The already-produced S3 batches with overflow values were capped in place to unblock the stuck reloads; post-rollout batches will load the true values once columns are
numeric(20,0).🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Tests