fix: error severity for invalid FC state -> reset

[meyer9]

Change the error severity for an invalid forkchoice state error to Reset so the engine resets if we get this error. This matches SynchronizationTask and op-node behavior.

Disables flaky test test_online_discv5_driver_bootstrap_mainnet.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
base	Ignored	Preview	May 6, 2026 10:08pm

[github-actions]

Missing doc comment on this variant. Every other variant in EngineBuildError has a /// doc comment, and the corresponding variant in SynchronizeTaskError (InvalidForkchoiceState) has one too. Per the project conventions (CLAUDE.md: no #![allow(missing_docs)], fix the underlying issue), this will likely trigger a missing_docs lint if it's enabled.

Also, minor naming inconsistency: SynchronizeTaskError uses InvalidForkchoiceState while this uses ForkchoiceStateInvalid. Not blocking, but worth considering aligning with the existing convention.

Suggested change

	#[error("Invalid forkchoice state")]
	ForkchoiceStateInvalid,
	/// The forkchoice state is invalid.
	#[error("Invalid forkchoice state")]
	ForkchoiceStateInvalid,

[refcell]

Took an initial pass and this LGTM

[meyer9]

This is failing rn, will open an issue to fix this flake in a forward PR.

[meyer9]

#2552

[github-actions]

Review Summary

Overall: This PR looks correct. The change properly adds ForkchoiceStateInvalid error handling to BuildTask, mapping INVALID_FORK_CHOICE_STATE_ERROR (-32008) to Reset severity. This aligns with the existing SynchronizeTask behavior.

What was reviewed

• error.rs: New ForkchoiceStateInvalid variant and Reset severity mapping
• task.rs: Error code detection in the map_err closure
• task_test.rs: New test covering both FCU v2/v3 paths
• engine_client.rs: Mock error injection support for FCU errors
• driver.rs: Flaky test annotation (reasonable — depends on live mainnet nodes)

Findings

No new issues beyond what the existing inline comment already raised (naming inconsistency: ForkchoiceStateInvalid here vs InvalidForkchoiceState in SynchronizeTask).

The error handling logic in task.rs:129-140 correctly:

1. Logs the original RpcError before inspecting it
2. Checks as_error_resp() for the specific error code
3. Falls back to AttributesInsertionFailed for all other RPC errors
4. Mirrors the identical pattern in SynchronizeTask (synchronize/task.rs:138-151)