feat: force commit batches at hardfork boundary

[Thegaram]

Purpose or design rationale of this PR

During today's Galileo testnet upgrade, we had the 2 last Feynman batches pending, with a number of Galileo batches after them. We’d expect the Feynman batches to be committed immediately, but this was not the case.

Root cause:

• We truncate the list of batches to submit based on the codec version, to ensure that we only commit batches of the same version together:

  scroll/rollup/internal/controller/relayer/l2_relayer.go

  Line 454 in 2ecc42e

  if batchesToSubmitLen > 0 && batchesToSubmit[batchesToSubmitLen-1].Batch.CodecVersion != dbBatch.CodecVersion {

• But if we have too few batches, then we will not submit the commit tx before the batch submission timeout:

  scroll/rollup/internal/controller/relayer/l2_relayer.go

  Line 471 in 2ecc42e

  if !forceSubmit && len(batchesToSubmit) < minBatches {

PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• feat: A new feature

Deployment tag versioning

Has tag in common/version.go been updated or have you added bump-version label to this PR?

• No, this PR doesn't involve a new deployment, git tag, docker image tag
• Yes

Breaking change label

Does this PR have the breaking-change label?

• No, this PR is not a breaking change
• Yes

Summary by CodeRabbit

• Chores

  • Version bumped to v4.7.8

• Bug Fixes

  • Ensure pending batches are forced to submit when a codec-version boundary is encountered between consecutive batches, preventing skipped submissions

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Bumps package version tag to v4.7.8 and updates relayer batch processing so ProcessPendingBatches sets forceSubmit = true when encountering a codec-version boundary between contiguous pending batches.

Changes

Cohort / File(s)	Summary
Version tag update common/version/version.go	Package-level version tag changed from "v4.7.7" to "v4.7.8".
Relayer batch submission logic rollup/internal/controller/relayer/l2_relayer.go	In ProcessPendingBatches, when a pending batch has a different CodecVersion than the previously queued batch, the code now sets forceSubmit = true in addition to breaking the loop.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Review points:
  • Confirm intended behavior when encountering codec-version boundaries and ensure downstream submission expectations are preserved.
  • Verify unit/integration tests or add coverage for boundary behavior in ProcessPendingBatches.

Possibly related PRs

• perf(relayer): submission strategy fix logs, use blocktime for submission strategy and log metrics. #1663 — Also modifies rollup/internal/controller/relayer/l2_relayer.go's ProcessPendingBatches (related submission/timeout/metrics changes).
• refactor(rollup-relayer): simplify construct commit batch payload #1673 — Refactors batch-with-chunks handling and touches ProcessPendingBatches.
• Fix unique chunk hash #1727 — Updates the same version tag constant in common/version/version.go.

Suggested labels

bump-version

Suggested reviewers

• yiweichi
• jonastheis

Poem

🐰 I hopped a tag to v4.7.8 today,
Batches march on, then stop at codec way.
When versions differ, I nudge them through,
Force the submit — that’s what rabbits do! 🥕✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title 'feat: force commit batches at hardfork boundary' directly describes the main change: forcing batch commits at codec version boundaries during hardfork transitions.
Description check	✅ Passed	The PR description includes the purpose/design rationale section explaining the problem and root cause, confirms the title follows conventional commits, and documents that the version tag was updated.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat-commit-batches-at-hardfork-boundary

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 65ecc3a and f96c060.

📒 Files selected for processing (1)

• common/version/version.go (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• common/version/version.go

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: tests
• GitHub Check: check
• GitHub Check: tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

rollup/internal/controller/relayer/l2_relayer.go (1)

450-479: Codec-version boundary now (correctly) forces submission; update comment/log for clarity

The new forceSubmit = true when encountering a codec-version change after at least one queued batch makes sense: it ensures the leading contiguous run of older-version batches is committed even if len(batchesToSubmit) < minBatches, preventing them from being stranded at a hardfork boundary while newer-version batches pile up.

Given this, two minor clarity points:

• The function-level comment (Lines 342–347) and the condition comment (“we only submit batches if we have a timeout or if we have enough batches”, Line 471) no longer fully describe the behavior; there is now an additional trigger: “codec-version boundary after at least one batch queued”.
• The log at Line 477 still says "Forcing submission of batches due to timeout" even when forceSubmit is only set because of the codec-version boundary or backlog size. That can be misleading when debugging fork transitions.

Consider updating comments and the log message to reflect all forceSubmit causes, e.g. include whether timeout/backlog/version-boundary triggered it or make the message reason-agnostic.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2ecc42e and 65ecc3a.

📒 Files selected for processing (2)

• common/version/version.go (1 hunks)
• rollup/internal/controller/relayer/l2_relayer.go (1 hunks)

🧰 Additional context used

🧠 Learnings (3)

📓 Common learnings

Learnt from: colinlyguo
Repo: scroll-tech/scroll PR: 1714
File: rollup/internal/controller/relayer/l2_relayer.go:1548-1555
Timestamp: 2025-07-29T16:38:24.647Z
Learning: In rollup/internal/controller/relayer/l2_relayer.go, the validateBatchFields function should error out when GetBatchByHash fails to find a parent batch. This is intentional behavior - missing parent batches represent genuine error conditions that should halt batch submission processing. Genesis batch handling occurs separately from normal batch validation flow.

Learnt from: Thegaram
Repo: scroll-tech/scroll PR: 1746
File: rollup/internal/controller/sender/sender.go:637-640
Timestamp: 2025-10-18T06:49:24.796Z
Learning: In the file `rollup/internal/controller/sender/sender.go`, the resubmission logic in `createReplacingTransaction` does not convert V0 blob sidecars to V1 when resubmitting transactions after the Fusaka upgrade. This is an accepted edge case because it's unlikely to occur, geth is expected to handle it gracefully, and manual recovery is available if needed.

📚 Learning: 2025-07-29T16:38:24.647Z

Learnt from: colinlyguo
Repo: scroll-tech/scroll PR: 1714
File: rollup/internal/controller/relayer/l2_relayer.go:1548-1555
Timestamp: 2025-07-29T16:38:24.647Z
Learning: In rollup/internal/controller/relayer/l2_relayer.go, the validateBatchFields function should error out when GetBatchByHash fails to find a parent batch. This is intentional behavior - missing parent batches represent genuine error conditions that should halt batch submission processing. Genesis batch handling occurs separately from normal batch validation flow.

Applied to files:

• rollup/internal/controller/relayer/l2_relayer.go

📚 Learning: 2025-10-18T06:49:24.796Z

Learnt from: Thegaram
Repo: scroll-tech/scroll PR: 1746
File: rollup/internal/controller/sender/sender.go:637-640
Timestamp: 2025-10-18T06:49:24.796Z
Learning: In the file `rollup/internal/controller/sender/sender.go`, the resubmission logic in `createReplacingTransaction` does not convert V0 blob sidecars to V1 when resubmitting transactions after the Fusaka upgrade. This is an accepted edge case because it's unlikely to occur, geth is expected to handle it gracefully, and manual recovery is available if needed.

Applied to files:

• rollup/internal/controller/relayer/l2_relayer.go

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: tests
• GitHub Check: check
• GitHub Check: tests

🔇 Additional comments (1)

common/version/version.go (1)

8-8: Version bump looks consistent with release metadata

Tag update to v4.7.6 keeps Version composition unchanged and is consistent with the PR’s intent. No issues here.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 36.59%. Comparing base (e75d6c1) to head (f96c060).

Files with missing lines	Patch %	Lines
rollup/internal/controller/relayer/l2_relayer.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1768      +/-   ##
===========================================
- Coverage    36.59%   36.59%   -0.01%     
===========================================
  Files          247      247              
  Lines        21238    21237       -1     
===========================================
- Hits          7773     7771       -2     
+ Misses       12636    12635       -1     
- Partials       829      831       +2     

Flag	Coverage Δ
rollup	35.44% <0.00%> (-0.01%)	⬇️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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