The latest Buf updates on your PR. Results from workflow CI / buf-check (pull_request).

Claude finished @julienrbrt's task in 1m 23s —— View job

Code Review

• Read changed files
• Analyze pruner logic
• Review tests
• Provide feedback

Overall this is a clean, well-scoped change. The core approach — using daAddress != "" to determine if DA is enabled and conditionally skipping the DA inclusion check — is straightforward and correct. A few notes below.

block/internal/pruner/pruner.go

Conflated error handling in pruneBlocks (line 122–127)

currentDAIncludedBz, err := p.store.GetMetadata(p.ctx, store.DAIncludedHeightKey)
if err == nil && len(currentDAIncludedBz) == 8 {
    currentDAIncluded = binary.LittleEndian.Uint64(currentDAIncludedBz)
} else {
    p.logger.Debug().Msg("skipping pruning: DA is enabled but DA included height is not available yet")
    return nil
}

The else branch conflates two distinct cases:

1. Key not found in store (expected early-lifecycle state — DA height not yet written)
2. A genuine store read error (unexpected)
3. Key found but with wrong length (data corruption)

For cases 2 and 3, silently skipping with a debug-level log may hide real issues. Consider logging at Warn level when err != nil or when the byte slice has an unexpected length, reserving the Debug log for the ErrNotFound case. Fix this →

pruneBlocks doesn't persist batchEnd as last pruned height

Looking at pruneBlocks, after calling p.store.PruneBlocks(p.ctx, batchEnd), there's no call to persist the new batchEnd as the last pruned block height (unlike pruneMetadata which calls p.setLastPrunedStateHeight). The pruner does call p.getLastPrunedBlockHeight to compute the batch — so presumably PruneBlocks on the store updates that key itself. Worth confirming this is handled inside store.PruneBlocks and not an omission.

block/internal/pruner/pruner_test.go

Missing regression test (noted by @alpe)

There's no test for the case where storeHeight < daInclusionHeight. The line upperBound = min(storeHeight, currentDAIncluded) at pruner.go:130 handles this, but it's untested. A node could be temporarily behind DA (e.g., store at height 50, DA says 100) — the pruner should use storeHeight (50) as the upper bound and not try to prune beyond what's stored. Fix this →

Comment/expectation discrepancy in TestPrunerPruneBlocksWithoutDA

Lines 110-113 check h <= 40 for pruned blocks, while line 122 checks h < 40 for exec metadata (PruneExec is called with batchEnd=40 and uses h < height). The comment on line 103 says "prune from height 1 up to min(0 + 40, 90) = 40". This is correct but the asymmetry between <= 40 for block data and < 40 for exec metadata (h=40 is kept in exec) should be explained in the test comment to avoid confusion.

TestPrunerPruneBlocksWithDAEnabled — verifies no-op when DA height missing, but not the normal DA path

The test confirms that pruning is skipped when DAIncludedHeightKey is absent. A complementary test that sets DAIncludedHeightKey and verifies pruning actually occurs with DA enabled would be valuable for completeness (and would exercise the regression @alpe mentioned above).

block/components.go

Clean, minimal change. Passing config.DA.Address to pruner.New is the correct approach.

docs/learn/config.md

The two new bullet points (lines 343–344) clearly explain the behavior difference between DA-enabled and DA-disabled pruning. Good addition.

Summary: The change is correct and well-structured. The main actionable items are: (1) improve error differentiation in the else branch of the DA height read, and (2) add the regression test for storeHeight < daInclusionHeight as requested by @alpe.

Summary of Changes

Hello @julienrbrt, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the block pruning logic to enable nodes to prune blocks regardless of whether Data Availability (DA) is configured. Previously, pruning was strictly tied to DA inclusion, which prevented non-DA nodes from managing their storage. The changes introduce a conditional pruning mechanism that adapts based on DA enablement, ensuring efficient disk space management for all node types while maintaining data integrity for DA-enabled setups.

Highlights

• Pruning Logic Enhancement: The block pruning mechanism has been refactored to allow pruning even when Data Availability (DA) is disabled, addressing a limitation where nodes without DA configured could not manage their disk space effectively.
• Conditional DA-Aware Pruning: A new daEnabled flag was introduced in the Pruner component, which determines whether pruning should rely on DA inclusion height. If DA is disabled, pruning proceeds based solely on the store's block height.
• Configuration Integration: The pruner.New function now accepts the DA address from the configuration, enabling the pruner to dynamically adapt its behavior based on whether DA is active.
• Expanded Test Coverage: New unit tests were added to thoroughly validate the pruning functionality under both DA-enabled and DA-disabled scenarios, ensuring correct behavior in various operational modes.
• Documentation Update: The config.md documentation was updated to clearly explain the different pruning behaviors when DA is enabled versus when it is not, providing better guidance for users.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Codecov Report

❌ Patch coverage is 71.42857% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 61.10%. Comparing base (1da7634) to head (d36055b).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #3075      +/-   ##
==========================================
+ Coverage   61.04%   61.10%   +0.05%     
==========================================
  Files         113      113              
  Lines       11440    11444       +4     
==========================================
+ Hits         6984     6993       +9     
+ Misses       3674     3663      -11     
- Partials      782      788       +6     

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