fix!(strata): use sequencer config for poll interval

[storopoli]

Description

The OL sequencer in strata was producing blocks every 1 second instead of respecting the configured sequencer.ol_block_time_ms in the sequencer.toml config file. The --duty-poll-interval/-i CLI flag defaulted to 1_000ms, and this poll interval drove the SequencerTimerInput tick rate. During chain startup/catchup, all block target timestamps are in the past, so every tick produced a block immediately -- making the poll interval the effective block time.

This removes the --duty-poll-interval/-i CLI flag and instead derives the sequencer service tick interval from ol_block_time_ms in the sequencer runtime config (sequencer.toml).

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor
• New or updated tests
• Dependency Update

Notes to Reviewers

This is breaking since it removes the --duty-poll-interval/-i CLI flag (Cc @voidash)

Done with the help of Opus 4.6 thinking high

Had to increase timeouts in test_epoch_progression and test_interaction_with_strata because now blocktime is respected and blocks are 5s and not 1s by default:

alpen/functional-tests-new/common/config/config.py

Lines 80 to 84 in 1e02884

	@dataclass
	class SequencerConfig:
	ol_block_time_ms: int = field(default=5_000)
	max_txs_per_block: int = field(default=100)
	block_template_ttl_secs: int = field(default=60)

Is this PR addressing any specification, design doc or external reference document?

• Yes
• No

If yes, please add relevant links:

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added (where necessary) tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.
• I have disclosed my use of AI in the body of this PR.

Related Issues

[codecov]

Codecov Report

❌ Patch coverage is 16.66667% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.88%. Comparing base (4f8f41c) to head (1e02884).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
bin/strata/src/sequencer/signer.rs	0.00%	6 Missing ⚠️
crates/alpen-ee/common/src/types/batch.rs	0.00%	6 Missing ⚠️
crates/consensus-logic/src/fork_choice_manager.rs	0.00%	2 Missing ⚠️
...es/alpen-ee/sequencer/src/update_submitter/task.rs	0.00%	1 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (4f8f41c) and HEAD (1e02884). Click for more details.

HEAD has 2 uploads less than BASE

Flag	BASE (4f8f41c)	HEAD (1e02884)
unit	2	1
functional	1	0

@@            Coverage Diff             @@
##             main    #1493      +/-   ##
==========================================
- Coverage   74.33%   64.88%   -9.45%     
==========================================
  Files         783      781       -2     
  Lines       73713    73635      -78     
==========================================
- Hits        54795    47780    -7015     
- Misses      18918    25855    +6937     

Flag	Coverage Δ
functional	?
unit	64.88% <16.66%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
bin/strata/src/args.rs	20.58% <ø> (-76.48%)	⬇️
crates/asm/worker/src/service.rs	79.79% <100.00%> (-6.07%)	⬇️
crates/ol/sequencer/src/service.rs	68.79% <100.00%> (-22.19%)	⬇️
crates/storage/src/managers/l1.rs	38.33% <ø> (-14.17%)	⬇️
...es/alpen-ee/sequencer/src/update_submitter/task.rs	0.00% <0.00%> (-92.79%)	⬇️
crates/consensus-logic/src/fork_choice_manager.rs	0.00% <0.00%> (ø)
bin/strata/src/sequencer/signer.rs	0.00% <0.00%> (-91.43%)	⬇️
crates/alpen-ee/common/src/types/batch.rs	82.29% <0.00%> (-8.82%)	⬇️

... and 219 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Commit: c1d1b67

SP1 Execution Results

program	cycles	success
EVM EE STF	1,320,994	✅
Checkpoint	5,226	✅
Checkpoint New	883,623	✅

[bewakes]

Block time and duty poll intervals are actually two different things although in our case polling duties based on block time probably is fine because there's no other duty that needs to be polled faster than this.

[bewakes]

Also this might conflict with what's being done in this PR, which keeps duty-poll-interval intact.

[storopoli]

Also this might conflict with what's being done in this PR, which keeps duty-poll-interval intact.

@krsnapaudel how you wanna handle this? I do see that #1490 is more wide-scoped than this one...

[krsnapaudel]

Also this might conflict with what's being done in this PR, which keeps duty-poll-interval intact.

@krsnapaudel how you wanna handle this? I do see that #1490 is more wide-scoped than this one...

@storopoli @bewakes Duty polling is sequencer signer thing afaik. So this is also related to separation of sequencer signer. I would leave duty polling interval around until @purusang's PR (#1497) for separation.

[krsnapaudel]

@storopoli You should also rebase so the old dbtool failures disappear.

[storopoli]

Closing this since we need the --duty-poll-interval/-i CLI flag for #1497. We need a new way to fix this. Opened STR-2614.