feat: add ResolveDependencies for concrete volume/metadata discovery#135
feat: add ResolveDependencies for concrete volume/metadata discovery#135gfyrag wants to merge 1 commit into
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI 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 |
aee00c8 to
0b8b90c
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #135 +/- ##
==========================================
+ Coverage 66.96% 67.10% +0.13%
==========================================
Files 47 49 +2
Lines 5068 5135 +67
==========================================
+ Hits 3394 3446 +52
- Misses 1477 1487 +10
- Partials 197 202 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Add ParseResult.ResolveDependencies() which resolves all balance and metadata reads a script depends on, returning concrete values rather than expression trees. This enables consumers (e.g. ledger v3) to: - Preload exact volumes needed before FSM execution - Compute an input hash for optimistic concurrency control - Detect drift between admission and execution time Unlike GetInvolvedAccounts (which returns expression trees requiring consumer-side resolution), ResolveDependencies returns concrete (account, asset) → balance and (account, key) → value maps. The consumer doesn't need to walk expression trees or handle deferred resolution. All features are supported transparently: meta() chains, balance() in account addresses, mid-script function calls, oneof, etc. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
0b8b90c to
52a99af
Compare
Note on
|
Context
Ledger v3 uses a Raft architecture where transactions go through two stages:
The admission layer needs to know which volumes to preload before executing the script — but the volumes depend on the script itself.
The current approach uses
GetInvolvedAccountswhich returns expression trees (InvolvedAccountExpr) that the consumer must resolve. This led to ~500 lines of expression tree walking code on the ledger side, with bugs (GetAmount/GetAsset extracting wrong component, IsValidCall never called) and limitations (balance-dependent account addresses rejected).Proposal
Add
ResolveDependencies()which returns concrete data instead of expression trees:The consumer provides a
Storecallback (same interface asRun), gets back concrete reads, and handles the rest (hashing, preloading, drift detection) on its side.How the ledger uses it
Admission: call
ResolveDependencies→ get volumes + metadata → hash inputs → preload into Raft orderFSM: call
ResolveDependenciesagain → hash inputs → compare with admission hash → if match, execute; if mismatch, reject (retryable)This is classic optimistic concurrency control.
What this replaces on the ledger side
resolveExprToString,resolveExprWithMetadata,collectFnMetaReads,ResolveDeferredAccountsInvolvedAccountExprtypesIsValidCall/ non-deterministic script rejectionImplementation
recordingStorewraps aStoreand records allGetBalances/GetAccountsMetadatacallsResolveDependenciesruns the script with the recording store, discards the execution result, returns the recorded readsTest plan
🤖 Generated with Claude Code