Tx evaluation#378
Conversation
Deploying blockfrost-platform with
|
| Latest commit: |
3bd7bfd
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://e1927172.blockfrost-platform.pages.dev |
| Branch Preview URL: | https://feat-tx-evaluation-rebased.blockfrost-platform.pages.dev |
michalrus
left a comment
There was a problem hiding this comment.
Hey, I started reviewing, but then noticed that it's a draft! Left a few comments either way :)
c702f03 to
a53a53c
Compare
3bcc5c5 to
e67b1a9
Compare
6980be7 to
f269525
Compare
|
Maybe let's have a simpler merge commit for the current conflicts? 🥺 Unless you're using |
|
I've just merged |
michalrus
left a comment
There was a problem hiding this comment.
I pushed another merge with main, because there were some more conflicts to resolve. I hope I did that correctly!
Now I see that cargo test tests are failing:
❯ cargo nextest run --workspace --lib --verbose
…
Summary [ 76.650s] 650 tests run: 195 passed, 455 failed, 0 skipped
Stuff like:
FAIL [ 1.058s] blockfrost-platform-error-decoder external::tests::test_cbor_0001_ConwayTreasuryValueMismatch_Coin_Coin
Or:
FAIL [ 1.086s] blockfrost-platform-error-decoder tests::specific::test_cbor_0013_ConwayWdrlNotDelegatedToDRep_KeyHash_KeyHash
|
Maybe the tests are failing because my commits updated |
|
Everything is working related to this PR. The CI failure is caused by updated ledger codebase coming from the |
So what do you suggest to be a solution here? Maybe update (I think we shouldn’t be merging "red" ❌ PRs.) |
|
@ginnun wait, but why did I get the same error in:
I don’t have your changes (the updated So the integration tests would also fail on |
|
Look here:
on 2026-02-19T02:55:30,167769000+00:00. |
The plan is to fix/update the code for |
Great! Here's a tracking issue for this new work: |
I suppose… Hmm, WDYT, @vladimirvolek? This temporary fix is in: |
a4a277d to
dde536f
Compare
6642500 to
1db6c61
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 70 out of 72 changed files in this pull request and generated 4 comments.
Comments suppressed due to low confidence (1)
src/server.rs:2
- This file is currently empty and the workspace root has no
[package], so it is unused. Keeping an emptysrc/server.rsin the repository is confusing and may suggest there is a root crate/module. Please remove it if it’s accidental.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
michalrus
left a comment
There was a problem hiding this comment.
Note to self for when this PR is close to a merge:
Let's have a small PR to move
testgen-hshandling onmainin accordance to what thetx-evalPR did – for better view of conflicts and what really changed
(requesting changes so that it's not lost)
@michalrus This is in the making. |
aca4175 to
3b95456
Compare
b625eed to
75aee91
Compare
- chore: add devshell tools and CI tweaks for tx evaluation - chore: update workspace deps for tx evaluation - feat(common): add lazy chain config loader and helpers - fix(node): improve CBOR validation error messages - feat(node): add chain config, ledger, and utxo helpers - feat: add bf-tx-evaluator crate with native and external evaluators - feat(platform): add /utils/txs/evaluate endpoints - test: add coverage for tx evaluate endpoints
3b95456 to
b02c4a6
Compare
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Failing tests are unrelated to this PR. For evaluate failure, please see blockfrost/blockfrost-tests#73 |
9d6a5ad to
3bd7bfd
Compare
michalrus
left a comment
There was a problem hiding this comment.
A couple questions – the most important one is about the mempool omission:
| pallas-network = { git = "https://github.com/txpipe/pallas.git", rev = "ed422bc0d5a09f77617d4882dd4c71089a8bcdb2" } | ||
| pallas-primitives = { git = "https://github.com/txpipe/pallas.git", rev = "ed422bc0d5a09f77617d4882dd4c71089a8bcdb2" } | ||
| pallas-traverse = { git = "https://github.com/txpipe/pallas.git", rev = "ed422bc0d5a09f77617d4882dd4c71089a8bcdb2" } | ||
| pallas-addresses = { git = "https://github.com/blockfrost/pallas.git", rev = "cfa0c633640f5989e44f50ed27efc38992f9ed0d" } |
There was a problem hiding this comment.
There has been one more commit since then in your PR – txpipe/pallas@9a83c74
|
|
||
| utxos.insert(TxoRef::from(&multi_era_in), EraCbor::from(multi_era_out)); | ||
| } | ||
| let mut node = node_pool.get().await?; |
There was a problem hiding this comment.
I don't see this comment here. Maybe more like FIXME, not TODO? 🫣
| @@ -37,5 +37,7 @@ | |||
| "/epochs/latest/parameters", | |||
| "/genesis", | |||
| "/addresses/{address}/transactions", | |||
| "/addresses/{address}/utxos" | |||
| "/addresses/{address}/utxos", | |||
| "/utils/txs/evaluate", | |||
There was a problem hiding this comment.
I should underline, we don't have mempool integration yet (Ogmois does use mempool + chain)
- So the implementation is not equivalent, even though we're deferring to Haskell code?
- Shouldn’t we add it before releasing? 👀
- How hard is it?
- And why isn’t it caught by
blockfrost-tests?
| Err(e) => { | ||
| tracing::warn!( | ||
| "ChainConfigWatch: failed to refresh chain config: {e}. Retrying in {}s.", | ||
| RETRY_INTERVAL.as_secs() | ||
| ); | ||
| tokio::select! { | ||
| () = time::sleep(RETRY_INTERVAL) => {}, | ||
| () = tx.closed() => { | ||
| tracing::info!("ChainConfigWatch: stopping monitor"); | ||
| return; | ||
| }, | ||
| } | ||
| }, |
There was a problem hiding this comment.
So between the epoch boundary and successful refresh, stale protocol params would be used by eval? And the refresh might only practically fail if a node is down?
There was a problem hiding this comment.
@michalrus Yes that is correct. Alternatively we can fail (or wait) evaluate calls on epoch boundary but that might be fragile. Another (bad) option is to never cache those values.
| let (tx, rx) = watch::channel(None); | ||
|
|
||
| tokio::spawn(async move { | ||
| monitor_loop(node_pool, tx).await; |
There was a problem hiding this comment.
Can this panic? 👀 It seems rather crucial for correct eval results, and we wouldn't restart it then, no?
| ) -> Result<MultiEraProtocolParameters, BlockfrostError> { | ||
| // Create a Conway protocol parameters struct from the ProtocolParam and GenesisConfig | ||
| let conway_pp: ConwayProtParams = ConwayProtParams { | ||
| minfee_a: pp.minfee_a.required("minfee_a")? as u32, |
There was a problem hiding this comment.
Why are they u64 in CurrentProtocolParam, but u32 in ConwayProtParams? Are these multiple conversions always safe?
| let tx_id = utxo | ||
| .get("transaction") | ||
| .and_then(|transaction| transaction.get("id")) | ||
| .unwrap_or(&Value::Null); |
There was a problem hiding this comment.
Is the null okay here, or should we error?
| - Native is based on `pallas-validate`. | ||
| - External is using `ledger` codebase via `testgen` Haskell binary. | ||
|
|
||
| `native` produces different evaluation results when compared to `external` at the moment. Knowing that `external` depends on the ledger codebase, we can consider `external` results accurate. |
There was a problem hiding this comment.
But we don’t implement the mempool part there? 👀
There was a problem hiding this comment.
Yes, no mempool handling. Haskell part doesn't fetch any data from any source. By design, it's the Rust parts that needs to fetch any data and pass it to forward.
| if let Some(first_result) = results.first() { | ||
| matches!(first_result, TxEvalResultV6::Success(_)) | ||
| } else { | ||
| true |
There was a problem hiding this comment.
Can you explain this true here? Why are empty results a success?
| #[derive(Serialize, Deserialize, Debug)] | ||
| #[serde(untagged)] | ||
| pub enum EvaluationError { | ||
| Evaluation(serde_json::Value), | ||
| Deserialization(DeserializationErrorData), | ||
| } |
There was a problem hiding this comment.
Since this is #[serde(untagged)], and the first variant is arbitrary JSON, the deserializer would never reach the second variant 🤔 Do we ever use the deserializer? If not, maybe let's drop it?
Resolves #306
Stacked on #537 - merge that one first.
Context
Implements tx evaluation APIs compatible with the Blockfrost.io version:
/utils/txs/evaluate/utils/txs/evaluate/utxosWhat is added
bf-tx-evaluatorcrate providing native (Rust, viapallas-validate) and external (Haskell, viatestgen-hs) evaluatorsChainConfigWatchinbf-node- a background task that watches the Cardano node and publishes protocol params + genesis config viatokio::sync::watch, refreshed only at epoch boundariesledger,utxo,chain_config_watchWhat is changed
blockfrost/pallaswithpallas-validate(phase2feature) for script evaluationpallas-hardanoformatting failure)secp256k1-sys), make/awk/diffutils (for integration tests)cardano-nodetrace silencing migrated to the newer APICARGO_PROFILE_DEV_DEBUG=0on integration-test jobs to reduce disk pressureWhat is scoped out (now in #537)
testgen-hssubprocess handling extracted fromcrates/node/src/cbor/into dedicatedbf-testgenandbf-error-decodercratestestgen-hsversion bump to10.6.3.1and release binary downloads switched toblockfrost/testgen-hsbuild_utilstarget detection helpers factored out