[draft] Fixes used by st0x.rest.api preview deployment#2561
Draft
alastairong1 wants to merge 4 commits intorainlanguage:mainfrom
Draft
[draft] Fixes used by st0x.rest.api preview deployment#2561alastairong1 wants to merge 4 commits intorainlanguage:mainfrom
alastairong1 wants to merge 4 commits intorainlanguage:mainfrom
Conversation
The sol! macro for ERC20 now uses the actual contract artifact
(`ERC20.sol/ERC20.json`) with `rpc` derives enabled, instead of the
generic IERC20 interface. This unblocks call/send paths that need the
RPC-aware instance type and matches what alloy now expects for the
`approveCall` schema (field is `value`, not `amount`).
Mechanical follow-on changes:
- All `approveCall { amount: ... }` call sites and decoded-call assertions
rename `amount` -> `value` to match the ERC20 ABI.
- `IERC20Instance` -> `ERC20Instance`, `IERC20::symbolCall` ->
`ERC20::symbolCall`, `IERC20::decimalsCall` -> `ERC20::decimalsCall`
in the common ERC20 helper, fuzz impls, and vaults tests.
No behavior change beyond the binding switch.
`FallbackLayer::with_active_transport_count(rpcs.len())` dispatches every request to ALL configured transports in parallel — the opposite of what operators expect when supplying multiple RPCs for load sharing or burst absorption. With N RPCs, every read becomes N reads, and downstream rate limits fire N times sooner. Set `active_transport_count = 1` so the FallbackLayer health-routes a single transport per request and falls back to others on error/429, preserving load-sharing semantics. Also short-circuit the empty-rpcs case before constructing the layer to make the error path obvious. No behavior change for single-RPC setups; multi-RPC setups stop amplifying requests.
500ms is below the writer-contention window that shows up under real ingest concurrency: parallel readers being held off by a single long write hit `SQLITE_BUSY` returns to the caller. 10s is conservative for WAL-mode reads and aligned with the upstream rusqlite default recommendation for high-concurrency workloads. No correctness change — just a longer wait window before surfacing SQLITE_BUSY to the application.
Adds an optional `signed_contexts: Option<&[Vec<SignedContextV1>]>` parameter to `get_order_quotes` and `get_order_quotes_batch`. When supplied, the per-order context (indexed by order position) is attached to each generated `QuoteV2` request as `signedContext`. When `None` (or out of range), behavior is unchanged: empty signedContext, matching the prior default. Why: callers gating order-fill on a signed context (e.g. an off-chain authorization passed via SignedContextInjector) need to quote with the same signed context they intend to take with — otherwise the gate check on the calculate-io side fails at simulation, producing misleading "no liquidity" results for orders that would actually fill. Backward compatible: every existing call site passes `None` and gets the previous behavior. Only one new parameter, no field renames.
Contributor
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 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
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.
Summary
Four independent changes, one commit each. Each is reviewable on its own and can be split into a standalone PR if upstream prefers:
1. `bindings: switch IERC20 interface to ERC20 contract bindings` (`55731bd`)
The `sol!` macro for ERC20 now uses the actual contract artifact (`ERC20.sol/ERC20.json`) with `rpc` derives enabled, instead of the generic IERC20 interface. Mechanical follow-on rename across all `approveCall { amount: ... }` call sites and decoded-call assertions: `amount` → `value` to match the ERC20 ABI. `IERC20Instance` → `ERC20Instance`, `IERC20::symbolCall` → `ERC20::symbolCall`, `IERC20::decimalsCall` → `ERC20::decimalsCall`.
2. `bindings: avoid request amplification in mk_read_provider` (`e0161ee`)
`FallbackLayer::with_active_transport_count(rpcs.len())` dispatches every request to ALL configured transports in parallel — the opposite of what operators expect when supplying multiple RPCs for load sharing. With N RPCs, every read becomes N reads, downstream rate limits fire N× sooner.
Set `active_transport_count = 1` so the FallbackLayer health-routes a single transport per request and falls back to others on error/429. No behavior change for single-RPC setups; multi-RPC setups stop amplifying.
3. `local_db: raise SQLite busy_timeout from 500ms to 10s` (`34bd830`)
500ms is below the writer-contention window seen under real ingest concurrency: parallel readers held off by a single long write hit `SQLITE_BUSY` immediately. 10s is conservative for WAL-mode reads.
4. `quote: thread per-order signed_contexts through batch quoting` (`76ca3b2`)
Adds an optional `signed_contexts: Option<&[Vec]>` parameter to `get_order_quotes` and `get_order_quotes_batch`. When supplied, the per-order context is attached to the generated `QuoteV2` request as `signedContext`. When `None`, behavior is unchanged.
Why: callers gating order-fill on a signed context (e.g. an off-chain authorization passed via `SignedContextInjector`) need to quote with the same signed context they intend to take with — otherwise the gate check on the calculate-io side fails at simulation, producing misleading "no liquidity" results for orders that would actually fill.
Backward compatible: every existing call site passes `None` and gets prior behavior.
Status