Skip to content

Move away from the #[maybe_async] usage, avoid TransactionProver#1122

Merged
drahnr merged 46 commits intonextfrom
bernhard-async-experimental
Aug 13, 2025
Merged

Move away from the #[maybe_async] usage, avoid TransactionProver#1122
drahnr merged 46 commits intonextfrom
bernhard-async-experimental

Conversation

@drahnr drahnr changed the title Move away from the #[maybe_async] usage, avoid TransactionProvider Move away from the #[maybe_async] usage, avoid TransactionProver Jul 31, 2025
@drahnr drahnr requested a review from bobbinth August 1, 2025 15:11
@drahnr drahnr force-pushed the bernhard-async-experimental branch from b5a3111 to dd42762 Compare August 4, 2025 16:48
@drahnr drahnr force-pushed the bernhard-async-experimental branch from 0539f67 to a5c3b96 Compare August 7, 2025 22:41
0_u32,
)
.unwrap()
FeeParameters::new(AccountId::new_unchecked(<[Felt; 2]>::default()), 0_u32).unwrap()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed a commit that changed this, turns out AccountId::dummy was behind the testing flag on miden-objects

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had to push another one because there were other occurrences

@bobbinth
Copy link
Contributor

bobbinth commented Aug 9, 2025

I believe that 0xMiden/miden-client#1104 should work from this branch. @igamigo - could you confirm? (you probably will need to update the dependencies to point to this branch).

So, as the next step, we should get this PR ready to merge into next. I think this mostly requires addressing feedback from #1143 - right?

@drahnr drahnr marked this pull request as ready for review August 11, 2025 17:06
Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thank you! I left some nits and questions inline (some of them are just a carry-over from #1143)

Comment on lines +5 to 11
[fee_parameters]
symbol = "MIDEN"
verification_base_fee = 0

[[fungible_faucet]]
decimals = 3
max_supply = 100_000_000
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's create an issue for refactoring this to be more inline with something like what is described in #1143 (comment).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +93 to +94
async move {
async move {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: why do we need nested async moves here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you use the variant with TryFutureExt::inspect_err rather than the Result::inspect_err, the instrument proc_macro

error[E0277]: the trait bound `Result<_, _>: FutureMaybeSend<Result<(), NtxError>>` is not satisfied
  --> crates/ntx-builder/src/transaction.rs:70:10
   |
66 |     #[instrument(target = COMPONENT, name = "ntx.execute_transaction", skip_all, err)]
   |     ---------------------------------------------------------------------------------- return type was inferred to be `Result<_, _>` here
...
70 |     ) -> impl FutureMaybeSend<NtxResult<()>> {
   |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `futures::Future` is not implemented for `Result<_, _>`
   |

is unhappy, since it generates a Result type from it, rather than a future, which causes compile issues.

The trailing async move {..} keeps the heuristic happy and compiles.

Comment on lines +106 to +108
let notes = Box::pin(self.filter_notes(&data_store, notes)).await?;
let executed = Box::pin(self.execute(&data_store, notes)).await?;
let proven = Box::pin(self.prove(executed)).await?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: is there an alternative to these Box::pin() or do we have to keep using them from now on?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do get clippy warnings due to future sizes, ``Box::pin` shifts pieces of it to the heap, which makes the wrapping future smaller and quiets the clippy warnings. Out future sizes exceeded 100 kBytes, which is already pretty heavy, mostly from having to carry plenty of stack residing state across await points.

Comment on lines +48 to +55
#[error("missing fee faucet for native asset {0}")]
MissingFeeFaucet(String),
#[error("fee error")]
FeeError(#[from] FeeError),
#[error("faucet account of {0} is not a fungible faucet")]
NativeAssetFaucetIsNotPublic(String),
#[error("faucet account of {0} is not public")]
NativeAssetFaucitIsNotAFungibleFaucet(String),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think most of these variants fall away if we make the native faucet a special section in the genesis toml file.

@drahnr drahnr merged commit 5cc3d45 into next Aug 13, 2025
8 checks passed
@drahnr drahnr deleted the bernhard-async-experimental branch August 13, 2025 12:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants