fix(deps): keep both libphonenumber artifacts on the same version - #1258
Merged
Conversation
#1241 and #1242 were meant to land together at 9.0.36, but Dependabot rebased #1242 onto a newer upstream release, so code/cash ended up with the Android port at 9.0.36 and Google's artifact at 9.0.37. That skew matters here: :shared:phone parses and formats with io.michaelrocks:libphonenumber-android, while :services:flipcash, :services:flipcash-compose, :services:opencode and :shared:onramp:coinbase validate with com.googlecode.libphonenumber:libphonenumber. Each artifact bundles its own copy of the libphonenumber metadata, so one patch of drift is enough for the two to disagree on whether a given number is valid — a class of bug that surfaces as an unexplained rejection for a handful of countries. The port lags upstream (9.0.36 is its latest), so it sets the ceiling. Pins -google back to 9.0.36 and documents the coupling in the catalog. Also groups both artifacts in dependabot.yml so future bumps arrive as a single PR. Grouping does not force matching versions — the port will still lag — but it puts any skew in one diff instead of two independently mergeable PRs. Verified with :apps:flipcash:app:assembleDebug plus the phone and encryption unit tests.
github-actions
Bot
added
type: fix
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
1 participant
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.
Follow-up to #1241 / #1242.
Those two were reviewed and merged as a pair precisely so the two libphonenumber artifacts would agree at
9.0.36. Between the review and the merge, #1242 hit a conflict and Dependabot rebased it onto a newer upstream release — socode/cashnow has:lib-phone-number-portio.michaelrocks:libphonenumber-androidlib-phone-number-googlecom.googlecode.libphonenumber:libphonenumberWhy the skew is worth fixing rather than ignoring
Both artifacts are on the runtime classpath and each bundles its own copy of the libphonenumber metadata. The class names don't collide (
io.michaelrocks.libphonenumber.android.*vscom.google.i18n.phonenumbers.*), so nothing breaks at build time — but the two are consulted at different points in the same flow::shared:phoneparses and formats with the port:services:flipcash,:services:flipcash-compose,:services:opencodeand:shared:onramp:coinbasevalidate with Google'sA metadata patch typically adjusts number ranges for a handful of countries. One patch of drift is enough for the client to format a number as valid and the services layer to reject it (or the reverse) — for some countries only, intermittently, with nothing in the stack trace pointing at a version mismatch.
9.0.36is the latest published version of the port (checked against Maven Central), so it sets the ceiling. This pins-googleback to match and documents the coupling in the catalog so the next bump doesn't silently re-skew.Dependabot grouping
Also groups both artifacts into one Dependabot PR. To be clear about what this does and doesn't buy: it does not force matching versions — the port will keep lagging, and a grouped PR will still propose 9.0.37/9.0.36. What it does is put the skew in a single diff you can see and correct, instead of two PRs that can each be merged on their own and look fine in isolation. That's exactly how this one got through.
Verification
./gradlew :apps:flipcash:app:assembleDebug— green (also confirms the other seven dependency bumps that just landed build together):apps:flipcash:shared:phone:testDebugUnitTest— green:libs:encryption:hmac:testAndroidHostTest— green (KMP module;testis ambiguous here,testAndroidHostTestis the real task)