Skip to content

Conversation

@Evalir
Copy link
Member

@Evalir Evalir commented Nov 25, 2025

There's no point of blocking when we send the bundle to flashbots. The only thing we do after is record metrics. This will matter more on a production environment where network lag could occur on services we don't control (flashbots). I think blocking on quincey/getting the nonce on prepare is OK.

No reason to block the entire loop on the time it takes to send the bundle and record metrics. This can happen in a spawned task while the loop just waits for the next value.
Copy link
Member Author

Evalir commented Nov 25, 2025

@Evalir
Copy link
Member Author

Evalir commented Nov 25, 2025

I'm also OK with not committing to this change now, and start tracking network request time.

let flashbots = self.flashbots().to_owned();
let signer = self.signer.clone();

tokio::spawn(async move {
Copy link
Member

Choose a reason for hiding this comment

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

this is not instrumented correctly. instrument the outer async move, then use in_current-span for the inner one

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.

3 participants