You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Address view: scope cold-cache calls Dune query and surface UDC v2 deploys
Three related fixes for visiting a recently deployed contract for the first
time:
- The cold-cache Dune contract-calls path used a `block_date >= '2024-01-01'`
floor, so a partition scan over 16 months ran even when the contract had
been deployed yesterday. We now resolve a deploy block via cache → pf
class-history → Voyager, look up its timestamp through `ds.get_block`
(cache → RPC), and pass `min_block_date = deploy_date - 1 day` to the
windowed query. Verified against Dune: identical rows at ~18x lower cost.
- `find_deploy_tx` was only invoked from the pf re-fetch branch, so when
another flow (tx-detail decode, class-info view) had already warmed
`class_history` but not `deploy_info`, the deploy summary never appeared.
Trigger the lookup whenever class history is cached but deploy info is
missing; suppress the duplicate launch from the pf branch.
- Register UDC v2 (0x02ceed65...) so deployments through it carry a label.
The `ContractDeployed` selector is unchanged, and our scanners already
match by event key rather than `from_address`, so v2 flows through the
same UDC path without further changes.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Voyager: wait for in-flight fetch instead of returning empty
The previous in-flight dedup short-circuited concurrent callers to an empty
`VoyagerLabelInfo`. That was fine for the original fire-and-forget UI label
use case, but broke a downstream consumer: when the cold-cache contract-calls
path tried to read `deploy_block` from voyager while the orchestration's
voyager fetch was already mid-flight, it got `None` and fell back to the
unscoped Dune query — exactly the slow path the dedup was supposed to help.
Replace the `HashSet<Felt>` slot tracker with a per-address
`tokio::sync::Mutex` map. The first caller acquires the lock and performs
the fetch; concurrent callers wait, then read the cached result. Backoff
and concurrency-cap behaviour are unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Extract calls Dune query plan into a pure helper, add unit tests
The cold-cache calls path picks between three Dune query variants
(top-delta, deploy-scoped windowed, unwindowed fallback) based on a chain
of cache + pf + Voyager lookups. Regressions back to the legacy unwindowed
`block_date >= '2024-01-01'` query are silent (just slow), so the choice
is worth covering with tests.
Pull the decision into `pick_calls_dune_query` — a sync function over plain
inputs (newest cached call's block+timestamp, deploy floor, deploy
timestamp). `fetch_address_contract_calls` does the IO to populate those
inputs and dispatches the resulting `CallsDuneQuery` to the matching Dune
method. No behaviour change.
Add six unit tests covering: warm cache (with and without a usable
timestamp), warm cache ignoring a deploy floor when one is also resolved,
cold cache + deploy_info, cold cache with no floor at all, and cold cache
with a floor but no timestamp (must fall back to unwindowed since the
windowed variant degrades to a full partition scan without a date hint).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments