More robust wait for block. by ZanCorDX · Pull Request #899 · flashbots/rbuilder

ZanCorDX · 2026-03-20T13:35:50Z

📝 Summary

Some new bug in reth (between 1.9.3 and 1.11.3) generated a rece condition that would give the last block but then when asked for it it's not there.
Now wait_for_block_header waits until the deadline no matter the errors it gets.

✅ I have completed the following steps:

Run make lint
Run make test
Added tests (if applicable)

claude · 2026-03-20T13:37:25Z

Claude finished @ZanCorDX's task in 1m 19s —— View job

PR Review: More robust wait for block

Read changed file and diff
Analyze code changes
Post review feedback

Summary

The refactoring to extract try_to_read_block_header and retry on all errors until the deadline is a reasonable approach for the reth race condition described. The core logic change — catching errors instead of propagating them — achieves the stated goal.

Issues found

Unnecessary async — try_to_read_block_header has no .await points; all provider calls are synchronous. It should be a regular fn to avoid the overhead of an unnecessary Future. (inline comment)
Typo in log message — "Failed to_read_block_header" should be "Failed to read block header". (inline comment)
Double logging per retry — Both the caller (line 491) and try_to_read_block_header (line 520) log at info on every "not found" iteration, producing two log lines per poll cycle. One should be removed or demoted to debug. (inline comment)
Silent swallowing of provider errors — The new code retries on all errors, including potential DB/provider failures that the old code would propagate immediately. This is acceptable for the race condition fix, but consider logging these at warn rather than info so genuine provider issues are visible in production.

claude · 2026-03-20T13:38:48Z

+        match try_to_read_block_header(block, parent_hash, payload_id, provider).await {
+            Ok(header) => return Ok(header),
+            Err(err) => {
+                info!(?err, "Failed to_read_block_header");


Typo: "Failed to_read_block_header" — looks like a copy-paste from the function name. Should be "Failed to read block header".

Also, logging provider errors (e.g. DB issues) at info level may make them hard to notice in production. Consider warn here since these are errors that were previously propagated as failures.

Suggested change

info!(?err, "Failed to_read_block_header");

info!(?err, "Failed to read block header");

claude · 2026-03-20T13:38:50Z

+        let current_parent_hash = provider
+            .header_by_number(block.checked_sub(1).unwrap_or(1))?
+            .map(|h| h.hash_slow());
+        info!(


When the header is not found (the else branch below), this logs at info level with details, and then the caller also logs the returned error at info level (line 491). This produces two log lines per retry iteration for the common "not found yet" case. Consider removing one of the two log sites or making the inner one debug to reduce noise.

Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>

claude · 2026-03-20T14:08:18Z

Claude finished @ZanCorDX's task in 1m 10s —— View job

PR Review: More robust wait for block

Read changed file and diff
Analyze code changes
Post review feedback

Summary

Good progress from the previous review — try_to_read_block_header was correctly changed from async fn to fn. However, three issues remain:

Compile error (blocking): The call site at line 488 still has .await on the now-synchronous try_to_read_block_header. Since eyre::Result<Header> doesn't implement Future, this won't compile. (inline comment)
Typo (minor): "Failed to_read_block_header" at line 491 — underscore instead of space. (inline comment)
Double logging (minor): Both the caller (line 491) and try_to_read_block_header (line 520-526) log at info on every "not found" iteration. (inline comment)

claude · 2026-03-20T14:09:35Z

-                sleep_duration = None;
-            } else {
-                sleep_duration = Some(time_to_sleep.try_into().unwrap());
+        match try_to_read_block_header(block, parent_hash, payload_id, provider).await {


Bug: .await on a non-async function. try_to_read_block_header was correctly changed to a regular fn (line 505), but this call site still has .await. Since eyre::Result<Header> does not implement Future, this should be a compile error.

Suggested change

match try_to_read_block_header(block, parent_hash, payload_id, provider).await {

match try_to_read_block_header(block, parent_hash, payload_id, provider) {

claude · 2026-03-20T14:09:37Z

+        match try_to_read_block_header(block, parent_hash, payload_id, provider).await {
+            Ok(header) => return Ok(header),
+            Err(err) => {
+                info!(?err, "Failed to_read_block_header");


Typo still present from previous review: "Failed to_read_block_header" should be "Failed to read block header".

Suggested change

info!(?err, "Failed to_read_block_header");

info!(?err, "Failed to read block header");

claude · 2026-03-20T14:09:39Z

+            ?current_parent_hash,
+            payload_id,
+            "Payload parent header not found, trying again"
+        );


Double logging is still present: this info! fires on every "not found" iteration, and the caller at line 491 also logs the returned error at info. Consider removing one or demoting this inner log to debug! to reduce noise.

claude · 2026-03-20T14:12:53Z

Claude finished @ZanCorDX's task in 46s —— View job

PR Review: More robust wait for block

Read changed file and diff
Analyze code changes
Post review feedback

Summary

The previous issues (.await on non-async fn, typo) are all fixed in this push. The refactoring is clean — try_to_read_block_header is correctly a synchronous fn, the loop structure is simpler, and the retry-on-all-errors behavior matches the stated goal of working around the reth race condition.

Remaining issue

Double logging per retry — still present. When the header isn't found, try_to_read_block_header logs at info with full context (lines 520-526), then returns an error, and the caller also logs that error at info (line 491). This produces two log lines per poll cycle. (inline comment)

claude · 2026-03-20T14:13:54Z

+        match try_to_read_block_header(block, parent_hash, payload_id, provider) {
+            Ok(header) => return Ok(header),
+            Err(err) => {
+                info!(?err, "try_to_read_block_header failed");


Double logging on "not found" iterations is still present. When the header isn't found, try_to_read_block_header logs at info with full context (line 520-526), then returns an error, and this line logs the error again at info. This produces two log lines per poll cycle for the common case.

Consider removing this outer log (the inner one has all the useful details), or demoting it to debug:

Suggested change

info!(?err, "try_to_read_block_header failed");

debug!(?err, "try_to_read_block_header failed");

ZanCorDX added 2 commits March 19, 2026 15:09

wait more for a block

686a2f0

fixed comments

9927e75

ZanCorDX requested a review from dvush as a code owner March 20, 2026 13:35

claude Bot reviewed Mar 20, 2026

View reviewed changes

Comment thread crates/rbuilder/src/live_builder/mod.rs Outdated

claude Bot reviewed Mar 20, 2026

View reviewed changes

dvush approved these changes Mar 20, 2026

View reviewed changes

Update crates/rbuilder/src/live_builder/mod.rs

411795e

Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>

claude Bot reviewed Mar 20, 2026

View reviewed changes

comment + fixed await

19ea8f5

claude Bot reviewed Mar 20, 2026

View reviewed changes

ZanCorDX merged commit c66f845 into develop Mar 20, 2026
10 checks passed

ZanCorDX deleted the dx/more-robust-wait-for-block branch March 20, 2026 14:35

Navigation Menu

Uh oh!

More robust wait for block. - #899

More robust wait for block.#899
ZanCorDX merged 4 commits into
developfrom
dx/more-robust-wait-for-block

ZanCorDX commented Mar 20, 2026

Uh oh!

claude Bot commented Mar 20, 2026 •

edited

Loading

Uh oh!

Uh oh!

claude Bot Mar 20, 2026

Uh oh!

claude Bot Mar 20, 2026

Uh oh!

claude Bot commented Mar 20, 2026 •

edited

Loading

Uh oh!

claude Bot Mar 20, 2026

Uh oh!

claude Bot Mar 20, 2026

Uh oh!

claude Bot Mar 20, 2026

Uh oh!

claude Bot commented Mar 20, 2026 •

edited

Loading

Uh oh!

claude Bot Mar 20, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	info!(?err, "Failed to_read_block_header");
	info!(?err, "Failed to read block header");

	match try_to_read_block_header(block, parent_hash, payload_id, provider).await {
	match try_to_read_block_header(block, parent_hash, payload_id, provider) {

	info!(?err, "try_to_read_block_header failed");
	debug!(?err, "try_to_read_block_header failed");

Uh oh!

Conversation

ZanCorDX commented Mar 20, 2026

📝 Summary

✅ I have completed the following steps:

Uh oh!

claude Bot commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: More robust wait for block

Summary

Issues found

Uh oh!

Uh oh!

claude Bot Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

claude Bot Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

claude Bot commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: More robust wait for block

Summary

Uh oh!

claude Bot Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

claude Bot Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

claude Bot Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

claude Bot commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: More robust wait for block

Summary

Remaining issue

Uh oh!

claude Bot Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

claude Bot commented Mar 20, 2026 •

edited

Loading

claude Bot commented Mar 20, 2026 •

edited

Loading

claude Bot commented Mar 20, 2026 •

edited

Loading