NonceManagerMiddleware failures when running concurrently

[fgimenez]

Version
v2.0.11 (https://github.com/gakonst/ethers-rs#40cc8cc5)

Platform
Linux arkham 6.7.4-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 5 22:21:14 UTC 2024 x86_64 GNU/Linux

Description
I'm sending a transaction to a smart contract function using code similar to this:

let tx_receipt = self
    .payments
    .book_service(U256::from_big_endian(&cluster_id.into_bytes()), amounts)
    .send()
    .await?
    .await?
    .unwrap();

self.payments is an instance of the bindings to a smart contract. The provider was created like this:

let provider = Arc::new(Provider::<Http>::try_from(rpc_url)?.with_signer(wallet.clone()).nonce_manager(wallet.address()))

When I run the code to send the transactions in multiple async tasks, I start getting errors like replacement transaction underpriced, which seems to reflect that the nonce was not properly updated.

Any help is very appreciated, thanks!

[fgimenez]

To give more context, I'm running a load test tool that executes the code above to send transactions. The tool spawns multiple clients using the same wallet for all of them.

The first thing I tried to fix the nonce issue was to put a lock around the code that sends the transaction. This completely fixed the problem, but the throughput was very bad.

Next, looking at the NonceManagerMiddleware code, I replaced this https://github.com/gakonst/ethers-rs/blob/master/ethers-middleware/src/nonce_manager.rs#L74-L80 (which AIUI could be problematic with concurrent access) to call instead initialize_nonce and take advantage of mutex guard's lock.

With this in place (and without the lock around my send transaction call), errors are back, but now instead of "replacement transaction underpriced" I get "already known" errors, as I understand it now the same transaction (same tx hash) is found more than once in the mempool? I wonder if this code https://github.com/gakonst/ethers-rs/blob/master/ethers-middleware/src/nonce_manager.rs#L152-L162 could also benefit from a lock for concurrent access?

Let me know if I can give any additional info.