fix: Set Era pipeline stage to last checkpoint when there is no target

[mediocregopher]

I observed the following behavior on a node which was started without a --debug.tip, after having manually dropped a stage:

2025-10-14T12:17:32.267719Z  INFO Preparing stage pipeline_stages=1/16 stage=Era checkpoint=23575428 target=None
2025-10-14T12:17:32.267733Z  INFO Executing stage pipeline_stages=1/16 stage=Era checkpoint=23575428 target=None
2025-10-14T12:17:32.268088Z  INFO Finished stage pipeline_stages=1/16 stage=Era checkpoint=0 target=None

As shown, the Era stage was setting its checkpoint to zero. This was occurring because when the target has already been reached Era immediately returns ready from poll_execute_ready:

reth/crates/stages/stages/src/stages/era.rs

Lines 149 to 151 in 5065890

	if input.target_reached() || self.item.is_some() {
	return Poll::Ready(Ok(()));
	}

(target_reached assumes a zero target block number if the target field is None.)

At this point self.item is None. When execute is then called Era has no work to do, but was returning the target (defaulting again to zero) rather than previous checkpoint:

reth/crates/stages/stages/src/stages/era.rs

Line 214 in 5065890

input.target()

If a stage was then manually dropped again then both Era (the first stage) and Finish (the last stage) would be zero. This check in check_pipeline_consistency would never hit, and no pipeline sync would be reran:

reth/crates/node/builder/src/launch/common.rs

Lines 930 to 942 in cec30cd

	// If the checkpoint of any stage is less than the checkpoint of the first stage,
	// retrieve and return the block hash of the latest header and use it as the target.
	if stage_checkpoint < first_stage_checkpoint {
	debug!(
	target: "consensus::engine",
	first_stage_checkpoint,
	inconsistent_stage_id = %stage_id,
	inconsistent_stage_checkpoint = stage_checkpoint,
	"Pipeline sync progress is inconsistent"
	);
	return self.blockchain_db().block_hash(first_stage_checkpoint);
	}
	}

Since the Finish stage is used to determine current block height generally, the node would then assume it has no blocks.

2025-10-14T13:59:36.340411Z  INFO Status connected_peers=0 latest_block=0

[yongkangc]

^ This has been making it really difficult to test the new trie changesets against main; everytime I would drop the MerkleChangeSets stage the node was getting into a weird state

do you mean that after this fix, it would be much easier to test the trieset changes against main? @mediocregopher

[mattsse]

nice find

[mattsse]

makes sense

[mattsse]

this checks out

[mediocregopher]

^ This has been making it really difficult to test the new trie changesets against main; everytime I would drop the MerkleChangeSets stage the node was getting into a weird state

do you mean that after this fix, it would be much easier to test the trieset changes against main? @mediocregopher

Now that I've figured this issue out I could potentially work around it, but yes with this fix in using reth-bench-compare on the trie changesets PR is much more straightforward