feat: add ftx clean up service

[jonesho]

This PR implements issue(s) #2103

Checklist

• I wrote new tests for my new core changes.
• I have successfully ran tests, style checker and build against my new changes locally.
• If this change is deployed to any environment (including Devnet), E2E test coverage exists or is included in this
  PR.
• I have informed the team of any breaking changes if there are any.

---

Note

Medium Risk
Introduces automated deletion of persisted forced-transaction records driven by finalized-state polling; misconfiguration or incorrect finalized-number handling could lead to unintended data loss or operational churn.

Overview
Adds a new ForcedTransactionsDbCleanUpService that periodically polls the latest finalized state and deletes forced-transaction DB rows with ftxNumber <= finalizedForcedTransactionNumber, skipping work when the finalized number hasn’t changed.

Wires this cleanup service into ForcedTransactionsApp lifecycle (start/stop) and adds an integration-style test asserting older finalized records are removed while newer ones remain.

^{Written by Cursor Bugbot for commit 48687fe. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Cleanup service polling interval not configurable via config

Low Severity

ForcedTransactionsDbCleanUpService is constructed without passing a pollingInterval, falling back to a hardcoded default of 5.seconds. All other periodic services in ForcedTransactionsApp (e.g., ftxInvalidityProofService) use intervals from the config object. This inconsistency means operators cannot tune the cleanup frequency without code changes, unlike every other polling service in the same app.

Additional Locations (1)

• coordinator/ethereum/forced-transactions/src/main/kotlin/linea/ftx/conflation/ForcedTransactionsDbCleanUpService.kt#L26-L27

 

[codecov-commenter]

Codecov Report

❌ Patch coverage is 96.42857% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 58.84%. Comparing base (077f833) to head (48687fe).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...x/conflation/ForcedTransactionsDbCleanUpService.kt	95.23%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #2719      +/-   ##
============================================
+ Coverage     58.74%   58.84%   +0.09%     
- Complexity     1625     1633       +8     
============================================
  Files           459      460       +1     
  Lines         18621    18649      +28     
  Branches       2023     2024       +1     
============================================
+ Hits          10939    10974      +35     
+ Misses         7016     7009       -7     
  Partials        666      666              

Flag	Coverage Δ		*Carryforward flag
hardhat	95.29% <ø> (ø)		Carriedforward from be64bde
kotlin	54.78% <96.42%> (+0.11%)	⬆️

*This pull request uses carry forward flags. Click here to find out more.

Files with missing lines	Coverage Δ
...src/main/kotlin/linea/ftx/ForcedTransactionsApp.kt	78.80% <100.00%> (+1.03%)	⬆️
...x/conflation/ForcedTransactionsDbCleanUpService.kt	95.23% <95.23%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Filter94]

FinalizationMonitorImpl is responsible for polling the finalized state and it has getLastFinalizationUpdate to access this information. Can't we use it?

[Filter94]

Also, clean up can be set up as a reaction on the finalization events with addFinalizationHandler

[jonesho]

@Filter94 Yes, that was in another PR: #2658, you can see the message here. This PR acts as an alternative that would require less changes but not placing the ftx table cleanup logic near the other similar cleanup logic

[Filter94]

But I don't see anything against putting the cleanup logic next to the other clean up logic we had. I see a comment about contract version switch being inside the FinalizationMonitorImpl rather than in a contract client somewhere