ethereum-optimism / ethereum-optimism/optimism
op-acceptance-tests: run conductor coverage against kona-node
- 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
Assessment
This issue has not been assessed yet.