Repository navigation
Conversation
Added interfaces for excluded pools and depth outcomes, updated depth result structure, and modified getDepth function to handle excluded pools.
|
@Naajih09 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
tsc --noEmit clean vitest 93 files, 1068 passing (up from 91 / 1052) dropped-tests none #433 from/to range args on getPriceHistory #456 make duplicate price points impossible at the database #456 is the better of the two: a uniqueness constraint in the schema rather than a check in the ingest path, so a duplicate cannot be written even by a code path that forgets to look. It carries a migration and adds 14 tests. Two others from this group were NOT merged -- both fail on their own, so this is not a merge-order problem: #389 (preserve decimal precision in GraphQL prices) 2 tsc errors, 31 test failures in isolation: src/aggregator/vwap.ts(250): Cannot find name 'isNonZeroDecimal' The function is called twice and never defined. #462 (read per-pool AMM fees from the venue) 4 tsc errors, 2 failures in isolation: src/api/rest.ts(281): Expected 4 arguments, but got 3 src/api/rest.ts(286): 'pairKey' is specified more than once The duplicate key is the shape a repeated base merge produces. Claude-Session: https://claude.ai/code/session_01USgemLt4Rnz4SGB1Srf3GB
Miracle656
left a comment
Miracle656
left a comment
There was a problem hiding this comment.
Fails on its own branch, so this is not about merge order:
src/api/rest.ts(281,33): error TS2554: Expected 4 arguments, but got 3
src/api/rest.ts(286,9): error TS2783: 'pairKey' is specified more than once, so this usage will be overwritten
4 type errors and 2 failing tests merged alone against current main.
The second one is worth looking at closely rather than just deleting the duplicate. 'pairKey' is specified more than once is the shape a repeated base merge produces — a key gets re-added alongside the one already there, the last wins, and whichever value was meant to apply silently does not. We have had the same thing happen in package.json on this project. Check which pairKey is the one you intend before removing either.
The arity error on line 281 suggests a helper gained a parameter underneath you, which a rebase will surface properly.
Reading per-pool AMM fees from the venue rather than assuming a flat rate is a real improvement and I want it — assumed fees are how a routing recommendation quietly becomes wrong. Fix the two errors and I will take it.
Closes #298
What this does
Pricing previously used a single fee constant for every AMM pool. Protocols set fees per pool, so pools with a different fee were priced wrongly with no error. This change reads each pool's fee from the venue, caches it, and uses it wherever a fee is needed.
networkin every response it touches and treats?network=as required on any new behavior, per the issue's guidance.Provenance
Responses that use a pool's fee include the pool ID, the fee in basis points, and when that fee was read. Excluded pools are listed with the reason.
Scope
SDEX order-book levels do not have a per-pool fee, so this PR covers AMM pools only. Any SDEX fee handling stays unchanged.
Known limits
How to verify