Repository navigation
fix(registry): skip accepts that cannot be stored instead of failing the resource (#1281) - #1282
Open
johnInarti wants to merge 1 commit into
Open
johnInarti wants to merge 1 commit into
johnInarti wants to merge 1 commit into
Conversation
…the resource register-origin / sync failed the whole resource when one accept could not be stored: - an 18-decimal token on Base (e.g. a peso stablecoin priced at 30.34 tokens = 30340000000000000000 atomic units) overflows the int64 maxAmountRequired column and made tx.accepts.upsert throw, taking the resource's storable USDC accept down with it; - several accepts on the same (scheme, network) raced on the unique key resourceId_scheme_network, so a later token could overwrite the server's preferred accept (typically USDC). selectStorableAccepts keeps the advertised order, skips unsupported networks (as before), skips amounts above int64 and keeps only the first accept per (scheme, network); skipped ones are logged. Tests cover all three paths and the int64 boundary. Fixes Merit-Systems#1281
Contributor
|
@johnInarti is attempting to deploy a commit to the Merit Systems Team on Vercel. A member of the Team first needs to authorize it. |
This branch has not been deployed
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.
Fixes #1281.
Problem
register-originand the resource sync fail the whole resource when a single accept cannot be stored:Accepts.maxAmountRequiredis PrismaBigInt(Postgresbigint, signed 64-bit). An 18-decimal token on Base priced above ~9.22 tokens does not fit; for example a peso stablecoin at 30.34 tokens is30340000000000000000atomic units.tx.accepts.upsertthrows (Could not convert argument value ... BigInt ... to ArgumentValue) and the resource's perfectly storable USDC accept is lost with it. Reproduced againsthttps://fractalai.net.co:422 no_valid_resources, 8 of 10 resources failed.resourceId_scheme_network, so when a server advertises USDC and another token on Base, the concurrent upserts race and a later accept can overwrite the server's preferred one.Change
selectStorableAccepts(accepts)(new, pure, tested) is applied inupsertResource:unsupportedAcceptskeeps its previous meaning);No schema migration. Storing amounts above int64 (e.g.
Decimal @db.Decimal(78,0)) is a larger change touching ~116maxAmountRequired: bigintcall sites; this PR only stops one unstorable accept from taking the resource down.Tests
apps/scan/src/services/db/resources/storable-accepts.test.ts: 18-decimal amount above int64 skipped while USDC is kept, first-per-(scheme, network) wins, unsupported network still skipped, int64 boundary, non-integer strings.vitest run src/services/db/resources/→ 9/9.tscshows no new errors (the 4 inresource.tsexist onmainwithout a generated Prisma client).