RPC Trace Add Param Validations

[Kbhat1]

Describe your changes and provide context

• Fixes issues where app state is pruned and debug_trace returns method handler crashed
• Refactor Validation for params for trace evmrpc
• Verifies txs + blocks #'s + block hashes all are within max_lookback_blocks + match a block number which the node has app history for

Testing performed to validate your change

• Unit tests
• Verifying on node

[codecov]

Codecov Report

❌ Patch coverage is 65.57377% with 21 lines in your changes missing coverage. Please review.
✅ Project coverage is 60.81%. Comparing base (06b7aaf) to head (a4f518b).
⚠️ Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
evmrpc/tracers.go	46.15%	18 Missing and 3 partials ⚠️

❌ Your patch status has failed because the patch coverage (65.57%) is below the target coverage (70.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2338      +/-   ##
==========================================
+ Coverage   60.76%   60.81%   +0.04%     
==========================================
  Files         314      314              
  Lines       30986    31041      +55     
==========================================
+ Hits        18830    18878      +48     
- Misses      10854    10857       +3     
- Partials     1302     1306       +4     

Files with missing lines	Coverage Δ
evmrpc/utils.go	76.21% <100.00%> (+2.84%)	⬆️
evmrpc/tracers.go	45.00% <46.15%> (+4.91%)	⬆️

... and 2 files 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.

[philipsu522]

is the config enough to validatae that the block exists/doesn't? what if someone increases their min-retain-blocks, but the history isn't there?

[Kbhat1]

Yup, these checks are for the state level @philipsu522 and directly calls api.backend.app.CommitMultiStore().GetEarliestVersion() which has the earliest historical version.

[Pray4LoveOnes]

// ValidateBlockAccess checks that a given blockNumber is still accessible
// based on configured retention parameters. It returns an error if the
// block is older than the allowed lookback.
func ValidateBlockAccess(blockNumber int64, params BlockValidationParams) error {
	// Check Tendermint block retention (min-retain-blocks)
	if params.MaxBlockLookback >= 0 &&
		blockNumber < params.LatestHeight-params.MaxBlockLookback {
		return fmt.Errorf("block %d is older than max lookback (%d)", blockNumber, params.MaxBlockLookback)
	}

	// Future safety: confirm we’re not asking beyond the latest height
	if blockNumber > params.LatestHeight {
		return fmt.Errorf("block %d is newer than latest height %d", blockNumber, params.LatestHeight)
	}

	return nil
}

---

And for the new test file, you can suggest it as an added block (you’d need to paste into evmrpc/tracers_test.go if it doesn’t exist yet):

package evmrpc

import (
	"testing"

	"github.com/stretchr/testify/require"
)

func TestValidateBlockAccess(t *testing.T) {
	params := BlockValidationParams{
		MaxBlockLookback: 100,
		LatestHeight:     200,
	}

	// Case 1: valid block in range
	err := ValidateBlockAccess(150, params)
	require.NoError(t, err, "block within lookback should pass")

	// Case 2: block too far back
	err = ValidateBlockAccess(50, params)
	require.Error(t, err, "block outside lookback should error")

	// Case 3: exactly at edge
	err = ValidateBlockAccess(100, params)
	require.NoError(t, err, "edge block should still pass")

	// Case 4: negative lookback disables pruning checks
	params.MaxBlockLookback = -1
	err = ValidateBlockAccess(1, params)
	require.NoError(t, err, "negative lookback should bypass checks")

	// Case 5: block beyond latest height
	params.MaxBlockLookback = 100
	err = ValidateBlockAccess(250, params)
	require.Error(t, err, "block newer than latest height should error")
}

---

That way maintainers can literally click “Apply suggestion” in GitHub’s review UI to merge your fix.

[yzang2019]

One idea, what if we actually return the correct error type from the SS KV/Storage layer to indicate the height is not available instead of adding this check in the api layer? API layer can just return the correct message automatically right?

[Pray4LoveOnes]

Yep, you're absolutely right, and your instinct is on point.. Instead of placing a height-not-available check in the API layer, return a typed error from the SS KV/Storage layer when a request is made for a height that hasn't been committed yet. This would allow the API layer to simply handle and forward the error cleanly without needing to embed chain-specific logic. Why this is the better architecture: Layer Responsibility Why this belongs there Storage / KV Layer Canonical source of truth It knows whether a block height is persisted or not. It's the correct place to determine and emit this error. API Layer User-facing conversion/forwarding Should translate errors into user-facing messages but not guess chain status or revalidate lower-layer assumptions. Suggested implementation plan: In Storage Layer (kv.go or storage.go) var ErrHeightUnavailable = errors.New("height not available") func (s *Store) GetStateAtHeight(height int64) (*State, error) { if height > s.LatestCommittedHeight { return nil, ErrHeightUnavailable } // proceed to fetch... } In API Layer (query_handler.go) state, err := store.GetStateAtHeight(req.Height) if errors.Is(err, storage.ErrHeightUnavailable) { return nil, status.Errorf(codes.NotFound, "Requested height %d is not yet committed", req.Height) } else if err != nil { return nil, status.Errorf(codes.Internal, "Unexpected storage error: %v", err) } Benefits: Decouples concerns, avoids leaking consensus-level detail into the API. Easier testing, errors are predictable and mockable. Future extensibility... if you later want to add retry-on-height-missing or alternative handling logic, it stays isolated.

…

On Thu, Aug 28, 2025, 12:41 PM Yiming Zang ***@***.***> wrote: *yzang2019* left a comment (sei-protocol/sei-chain#2338) <#2338 (comment)> One idea, what if we actually return the correct error type from the SS KV/Storage layer to indicate the height is not available instead of adding this check in the api layer? API layer can just return the correct message automatically right? — Reply to this email directly, view it on GitHub <#2338 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVBXSPW5GCUC2KXN2W4ZTZL3P45ODAVCNFSM6AAAAACE4NPRR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMZUGM4TCMZXGY> . You are receiving this because you commented.Message ID: ***@***.***>

[Kbhat1]

Closing in favor of root cause fix at sei-db layer: sei-protocol/sei-db#105