ethereum-optimism / ethereum-optimism/optimism

op-acceptance-tests: run conductor coverage against kona-node

Open
#21,903 0 comments 0 reactions 1 assignee Claimed by @joshklop View on GitHub
A-devstack A-kona A-op-conductor C-test
Dominant language
Go
Stars
6.5k
Forks
4k
Avg merge
2d 18h
Merged PRs (30d)
134

Description

## Summary

Enable the conductor acceptance suite to run against real `kona-node` sequencers, using the same behavioral requirements as op-node.

This depends on #21902, which tracks moving the broader conductor system coverage from `op-e2e` into `op-acceptance-tests`.

## Current state

The existing conductor acceptance test explicitly skips Kona:

- `op-acceptance-tests/tests/base/conductor/leadership_transfer_test.go`

The underlying preset is op-node-specific:

- `op-devstack/sysgo/singlechain_variants.go`
- `startConductorNode` accepts `*OpNode` and mutates op-node configuration directly.

The test under `rust/kona/tests/node/common/conductor_test.go` is also not real Kona coverage: `rust/kona/tests/node/utils/mixed_preset_with_conductor.go` delegates to the same op-node-only `presets.NewMinimalWithConductors` preset.

## Scope

### Devstack support

- Generalize conductor-managed CL setup around backend-neutral capabilities:
- user RPC endpoint;
- configure conductor RPC;
- force stopped startup;
- lifecycle/restart control.
- Preserve the existing op-node implementation.
- Add a `KonaNode` implementation using production CLI/RPC paths.
- Use stable RPC endpoints or TCP proxies to resolve the startup dependency between `kona-node` and `op-conductor` without reserving flaky fixed ports.
- Start all conductor-managed Kona sequencers stopped.
- Configure Kona's admin RPC, conductor RPC, L1/L2 endpoints, and P2P connectivity required by conductor health checks and failover.

### Shared acceptance coverage

Run the same conductor behavior tests against:

- op-node sequencers;
- Kona sequencers.

Do not add client-specific assertion branches. Product incompatibilities exposed by the shared suite should be fixed in Kona or tracked explicitly.

At minimum, Kona coverage should verify:

- cluster bootstrap with exactly one active sequencer;
- explicit leadership transfer and active-state handoff;
- continued block production and hash convergence after transfer;
- active sequencer failure and automatic failover;
- disaster-recovery override;
- conductor proxy behavior;
- unsafe payload commit fencing during conductor RPC failure.

### Kona compatibility likely exercised by the suite

Audit and test the Kona implementation for:

- conductor RPC timeout wiring;
- `conductor_overrideLeader` parameter compatibility;
- leadership and unsafe-head validation in `admin_startSequencer`;
- committing a payload to conductor before canonicalizing or gossiping it;
- handling ambiguous commit failures/timeouts without publishing an uncommitted payload.

Fast Rust integration tests should cover these internal invariants in addition to the full acceptance tests.

## Acceptance criteria

- [ ] The conductor preset can launch a three-member conductor cluster backed by real `kona-node` processes.
- [ ] No conductor acceptance test skips based on `DEVSTACK_L2CL_KIND=kona-node`.
- [ ] The shared suite passes against both op-node and Kona without client-specific assertion branches.
- [ ] CI has an explicit Kona conductor acceptance job or matrix entry that builds and runs the real Kona binary.
- [ ] The fixture asserts that its CL nodes are actually Kona, preventing silent fallback to op-node.
- [ ] Leadership handoff verifies active state, block progression, and hash convergence.
- [ ] Conductor commit failure cannot result in canonicalization or gossip of an uncommitted Kona payload.

## Related

- #21902
- #16418
- Archived upstream issues:
- https://github.com/op-rs/kona/issues/3094
- https://github.com/op-rs/kona/issues/3095

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.