feat(tracing): adding forced inclusion tracing

[chatton]

Overview

ref #2956

Add tracing for forced inclusion

[github-actions]

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

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	✅ passed	✅ passed	Jan 20, 2026, 8:25 AM

[gemini-code-assist]

Summary of Changes

Hello @chatton, 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 integrates OpenTelemetry tracing into the mechanism responsible for retrieving forced inclusion transactions from the Data Availability (DA) layer. By introducing a tracing wrapper and refactoring the retriever into an interface, the system gains improved visibility into the performance and flow of forced inclusion events, allowing for easier debugging and monitoring without altering the core retrieval logic. The tracing is enabled conditionally based on the application's instrumentation configuration.

Highlights

• Tracing Integration: Introduced OpenTelemetry tracing for the ForcedInclusionRetriever to enhance observability of forced inclusion transaction retrieval.
• Interface Refactoring: The ForcedInclusionRetriever has been refactored into an interface, with the concrete implementation renamed to forcedInclusionRetriever.
• Tracing Wrapper: A new tracedForcedInclusionRetriever struct and withTracingForcedInclusionRetriever function were added to conditionally wrap the base retriever with tracing capabilities.

🧠 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.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[claude]

Claude finished @chatton's task in 1m 43s —— View job

---

Comprehensive Code Review

I've completed a thorough review of the forced inclusion tracing implementation. Overall, the implementation is well-structured and follows established patterns in the codebase. The decorator pattern is correctly applied, and the code integrates cleanly with existing OpenTelemetry tracing infrastructure.

---

✅ Strengths

1. Consistent Architecture: The implementation mirrors the tracing patterns used in da_retriever_tracing.go and da_submitter_tracing.go, maintaining architectural consistency across the codebase.

2. Clean Interface Refactoring: Converting ForcedInclusionRetriever from a struct to an interface (block/internal/da/forced_inclusion_retriever.go:19-23) is the correct approach for applying the decorator pattern.

3. Proper Context Propagation: The traced context is correctly propagated through the call chain (forced_inclusion_tracing.go:27-31), ensuring span context flows through nested operations.

4. Meaningful Telemetry: The span attributes capture relevant operational data (da.height, event boundaries, tx_count) that will aid in debugging and monitoring.

---

⚠️ Critical Issue: Missing Test Coverage

Severity: High

The primary concern is the 15.62% patch coverage reported by Codecov, with 25 lines missing coverage in the new tracing file.

Current State:

• ❌ No tests found for tracedForcedInclusionRetriever
• ❌ No tests found for withTracingForcedInclusionRetriever
• ✅ Tests exist for similar tracing wrappers (e.g., tracing_test.go has tests for DA client tracing)

Expected:
The codebase has a strong testing pattern for tracing wrappers. For example, block/internal/da/tracing_test.go provides comprehensive tests including:

• Success path verification (span creation, attributes)
• Error path verification (error recording, status codes)
• Attribute correctness validation

Recommendation:
Add tests for the forced inclusion tracing wrapper following the established pattern:

// block/internal/da/forced_inclusion_tracing_test.go

func TestTracedForcedInclusionRetriever_Success(t *testing.T) {
    // Test successful retrieval with correct span attributes
    // Verify: span name, da.height, event.start_da_height, event.end_da_height, event.tx_count
}

func TestTracedForcedInclusionRetriever_Error(t *testing.T) {
    // Test error path with proper error recording
    // Verify: span error recording, status codes.Error
}

func TestTracedForcedInclusionRetriever_NotConfigured(t *testing.T) {
    // Test ErrForceInclusionNotConfigured case
}

Add test coverage for forced inclusion tracing →

---

📋 Minor Observations

1. Tracer Naming Consistency

Location: block/internal/da/forced_inclusion_tracing.go:22

Current:

tracer: otel.Tracer("ev-node/forced-inclusion")

Observation: Other tracers in the codebase use different naming conventions:

• da_retriever_tracing.go:26 → "ev-node/da-retriever"
• da_submitter_tracing.go:23 → "ev-node/da-submitter"

Recommendation: Consider using "ev-node/forced-inclusion-retriever" for consistency and clarity about what component is being traced.

2. Stop() Method Tracing

Location: block/internal/da/forced_inclusion_tracing.go:52-54

Observation: The Stop() method delegates to the inner implementation without creating a span. This is appropriate for lifecycle methods, but worth noting for completeness.

Status: ✅ Acceptable as-is. Stop operations are typically synchronous cleanup and don't require span tracking.

3. Public API Exposure

Location: block/public.go:72-88

Observation: The public API correctly exposes the interface without leaking internal tracing implementation details. The factory function automatically applies tracing when configured, which is the right abstraction level.

Status: ✅ Well-designed public API.

---

🔒 Security Considerations

✅ No security issues identified:

• No credential exposure in tracing attributes
• No PII or sensitive data in span attributes
• Transaction hashes are appropriately included for debugging
• Context propagation doesn't leak sensitive information

---

⚡ Performance Considerations

✅ No performance concerns:

• Tracing overhead is minimal (span creation/attributes are lightweight)
• Conditional tracing activation (block/internal/da/forced_inclusion_retriever.go:70-72) ensures zero overhead when tracing is disabled
• No memory leaks or goroutine issues in the tracing wrapper
• Attributes are set after successful operations, avoiding wasted work on errors

---

📝 Documentation

✅ Documentation is adequate:

• Interface methods have clear docstrings (forced_inclusion_retriever.go:19-23)
• Public API has explanatory comments (public.go:72-88)
• Tracing wrapper could benefit from a package-level comment explaining the decorator pattern, but this is consistent with other tracing files

---

🎯 Summary

Category	Status	Notes
Code Quality & Architecture	✅ Excellent	Follows established patterns
Error Handling	✅ Good	Proper error recording in spans
Security	✅ Good	No sensitive data exposure
Performance	✅ Good	Minimal overhead, conditional activation
Testing	⚠️ Needs Work	15.62% coverage - tests required
Documentation	✅ Adequate	Consistent with codebase standards

---

✅ Approval Recommendation

Recommendation: Approve with follow-up

The implementation is technically sound and production-ready. However, the missing test coverage should be addressed to maintain the project's quality standards. I recommend:

1. Option A (Preferred): Add tests for the tracing wrapper before merging (estimated 30-45 minutes of work)
2. Option B: Merge now and create a follow-up issue to add tests (risk: tests may be forgotten)

The choice depends on your team's priorities and velocity requirements. Given the low risk of the changes (pure decorator with no business logic), Option B is acceptable if you need to land this quickly, but Option A is strongly preferred.

---

Overall Assessment: 🟢 LGTM with recommendations

The code is well-written, follows Go best practices, and integrates cleanly with the existing tracing infrastructure. Once test coverage is added, this will be an exemplary implementation.

---

[gemini-code-assist]

Code Review

This pull request introduces OpenTelemetry tracing for the forced inclusion transaction retrieval process. This is achieved by refactoring ForcedInclusionRetriever from a struct into an interface and then applying the decorator pattern to wrap the core implementation with a tracing layer. The changes are well-structured, consistent with existing tracing patterns in the codebase, and correctly propagate the tracing context. The implementation is clean, and I found no issues with the proposed changes.

[codecov]

Codecov Report

❌ Patch coverage is 15.62500% with 27 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.33%. Comparing base (9ad4016) to head (174c4a0).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
block/internal/da/forced_inclusion_tracing.go	0.00%	25 Missing ⚠️
block/internal/da/forced_inclusion_retriever.go	71.42%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2997      +/-   ##
==========================================
- Coverage   59.53%   59.33%   -0.20%     
==========================================
  Files         107      108       +1     
  Lines       10075    10103      +28     
==========================================
- Hits         5998     5995       -3     
- Misses       3447     3477      +30     
- Partials      630      631       +1     

Flag	Coverage Δ
combined	59.33% <15.62%> (-0.20%)	⬇️

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.