chore: adding tracing for da submitter

[chatton]

Overview

ref #2956

Add tracing for da submitter

[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 19, 2026, 1:49 PM

[claude]

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

---

Code Review Complete ✅

I've completed a comprehensive review of the tracing additions for the DA submitter. Overall, this is a well-implemented, production-ready change that follows consistent patterns from the rest of the codebase. Below is my detailed analysis.

---

Summary

This PR adds OpenTelemetry tracing instrumentation to the DA (Data Availability) submitter component, specifically wrapping the DASubmitterAPI interface methods (SubmitHeaders and SubmitData). The implementation follows the decorator pattern used elsewhere in the codebase and includes comprehensive test coverage.

Changes:

• Renamed daSubmitterAPI → DASubmitterAPI (exported interface)
• Added tracedDASubmitter wrapper with OpenTelemetry spans
• Integrated tracing into both sync and aggregator node initialization paths
• Added comprehensive unit tests for all tracing scenarios

---

Code Quality & Architecture ✅

Strengths:

• Consistent decorator pattern: Follows the same WithTracing* pattern used for other components (sequencer, block producer, etc.)
• Clean separation: Tracing logic is isolated in dedicated files, not mixed with business logic
• Interface compliance: Proper use of compile-time interface verification (var _ DASubmitterAPI = (*tracedDASubmitter)(nil))
• Idiomatic Go: Code adheres to effective-go conventions with proper naming, error handling, and structure

Minor Observations:

• Interface naming change (daSubmitterAPI → DASubmitterAPI) is good - exported interface allows the decorator pattern to work across package boundaries
• The tracer name "ev-node/da-submitter" is consistent with other tracers in the codebase

Verdict: Excellent architecture that integrates seamlessly with existing patterns.

---

Error Handling & Resilience ✅

Strengths:

• Errors are properly recorded in spans with span.RecordError(err) and status set via span.SetStatus(codes.Error, err.Error())
• Error propagation is correct - the wrapper doesn't swallow or modify errors
• Span cleanup is guaranteed via defer span.End()
• Context is properly threaded through the call chain

No Issues Found: Error handling follows OpenTelemetry best practices.

---

Security ✅

Analysis:

• No sensitive data (credentials, keys, secrets) is logged in span attributes
• The tracing only captures metadata: counts, sizes, and height ranges
• Height values and byte sizes are safe to include in traces
• No input validation issues - the wrapper delegates to inner implementation

Verdict: No security concerns identified.

---

Performance & Resource Efficiency ✅

Strengths:

• Minimal overhead: Only adds span creation and simple calculations (byte counting, height ranges)
• Span attributes are set efficiently using the builder pattern
• No unnecessary allocations or blocking operations
• Byte size calculation uses a simple loop over slices that are already in memory

Observations:

• The total bytes calculation (da_submitter_tracing.go:41-45, da_submitter_tracing.go:74-78) is O(n) where n is the number of items, but this is negligible compared to the actual DA submission work
• Tracing is opt-in via config.Instrumentation.IsTracingEnabled(), so there's zero overhead when disabled

Verdict: Excellent performance characteristics with minimal overhead.

---

Testing & Reliability ⭐ Outstanding

Strengths:

• Comprehensive test coverage: 6 distinct test cases covering success, error, and edge cases
• Proper test isolation: Each test uses a fresh SpanRecorder and TracerProvider
• Cleanup handled correctly: t.Cleanup() ensures TracerProvider shutdown
• Edge case coverage: Tests include empty header/data arrays
• Attribute validation: Uses helper testutil.RequireAttribute for asserting span attributes
• Error validation: Verifies both error codes and descriptions in spans

Test Cases:

1. ✅ TestTracedDASubmitter_SubmitHeaders_Success - Happy path with multiple headers
2. ✅ TestTracedDASubmitter_SubmitHeaders_Error - Error handling and span status
3. ✅ TestTracedDASubmitter_SubmitHeaders_Empty - Edge case with empty inputs
4. ✅ TestTracedDASubmitter_SubmitData_Success - Happy path for data submission
5. ✅ TestTracedDASubmitter_SubmitData_Error - Error handling for data submission
6. ⚠️ Missing: TestTracedDASubmitter_SubmitData_Empty - Would be good for completeness (but not critical)

Mock Implementation:

• Simple, focused mock that allows injecting behavior via functions
• Properly implements the DASubmitterAPI interface

Verdict: Exemplary test quality. This is production-ready code.

---

Documentation & Developer Experience ✅

Strengths:

• Clear package-level documentation
• Function and type comments explain purpose
• Consistent naming conventions make code self-documenting
• Integration points in components.go are clear with conditional wrapping

Observations:

• The exported DASubmitterAPI interface is now usable by other packages
• The wrapping logic in components.go:160-163 and components.go:262-265 is straightforward and easy to understand

Minor Enhancement Opportunity:

• Could add a comment explaining why the interface was exported (to enable decorator pattern), but this is optional

Verdict: Good developer experience with clear, maintainable code.

---

Integration Quality ✅

Changes in components.go:

• Properly integrated into both NewSyncComponents and NewAggregatorComponents
• Conditional wrapping based on config.Instrumentation.IsTracingEnabled()
• Follows the same pattern as other tracing integrations (syncer, sequencer, executor)

Consistency Check:

// Sync nodes (components.go:160-163)
var daSubmitter submitting.DASubmitterAPI = submitting.NewDASubmitter(...)
if config.Instrumentation.IsTracingEnabled() {
    daSubmitter = submitting.WithTracingDASubmitter(daSubmitter)
}

// Aggregator nodes (components.go:262-265)
var daSubmitter submitting.DASubmitterAPI = submitting.NewDASubmitter(...)
if config.Instrumentation.IsTracingEnabled() {
    daSubmitter = submitting.WithTracingDASubmitter(daSubmitter)
}

Both paths are identical - good consistency!

---

Span Attributes & Observability Quality ⭐

Captured Metrics:

Headers (SubmitHeaders):

• header.count - Number of headers being submitted
• header.total_bytes - Total size of marshalled headers
• header.start_height - First header height (if any)
• header.end_height - Last header height (if any)

Data (SubmitData):

• data.count - Number of data items being submitted
• data.total_bytes - Total size of marshalled data
• data.start_height - First data height (if any)
• data.end_height - Last data height (if any)

Quality Assessment:

• Attribute names follow conventions (<resource>.<metric> pattern)
• Metrics provide valuable observability into DA submission patterns
• Height ranges enable tracking submission lag and batching behavior
• Byte sizes help identify performance issues or oversized submissions

Verdict: Excellent observability instrumentation.

---

Findings Summary

Critical Issues: 0 ✅

No critical issues found.

Major Issues: 0 ✅

No major issues found.

Minor Suggestions: 1

1. Optional: Add empty data test (da_submitter_tracing_test.go)
   • Currently missing TestTracedDASubmitter_SubmitData_Empty to mirror the headers test
   • Not critical since the logic is identical, but would improve symmetry
   • Add empty data test →

Positive Highlights: 🌟

1. Consistent with codebase patterns - Follows established tracing patterns perfectly
2. Production-ready quality - Comprehensive tests, proper error handling, clean code
3. Zero breaking changes - Only exports interface, all existing code compatible
4. Excellent test coverage - 6 tests covering success, error, and edge cases
5. Good observability - Captures meaningful metrics for monitoring DA submissions

---

Recommendation

✅ APPROVE - This PR is ready to merge.

The implementation is clean, well-tested, and follows all Go best practices. The tracing instrumentation will provide valuable observability into DA submission behavior without introducing performance overhead or security risks.

The only suggestion is an optional test addition for completeness, but the existing test coverage is already excellent.

Great work on maintaining consistency with the existing tracing infrastructure! 🎉

---

Tasks

• Read all changed files
• Review code quality & architecture
• Review error handling & resilience
• Review security considerations
• Review performance & resource efficiency
• Review testing & reliability
• Review documentation & developer experience
• Provide final feedback and recommendations

---

[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 DASubmitter component to enhance observability of data availability submissions. It introduces a new tracing wrapper that captures key metrics and contextual information for submission operations, which can be enabled via configuration. The changes also include a minor refactoring of the DASubmitterAPI interface and comprehensive unit tests to ensure the reliability of the new tracing features.

Highlights

• OpenTelemetry Tracing for DASubmitter: Introduced OpenTelemetry tracing capabilities for the DASubmitter component, allowing for detailed observability into data availability submission operations.
• Conditional Tracing Activation: The tracing functionality is conditionally applied to the DASubmitter instance within NewSyncComponents and NewAggregatorComponents based on the Instrumentation.IsTracingEnabled() configuration.
• Detailed Span Attributes: The new tracedDASubmitter wrapper records spans for SubmitHeaders and SubmitData methods, including attributes such as header/data count, total marshalled bytes, and the height range of submitted items.
• Interface Refactoring: The internal daSubmitterAPI interface was renamed to DASubmitterAPI for improved naming consistency and visibility.
• Comprehensive Unit Tests: Added dedicated unit tests for the tracedDASubmitter to verify correct tracing behavior, attribute capture, and error propagation for both SubmitHeaders and SubmitData methods.

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

[gemini-code-assist]

Code Review

This pull request introduces OpenTelemetry tracing for the DA submitter, which is a valuable addition for observability. The implementation uses a decorator pattern to wrap the existing DASubmitter with tracing logic, which is a clean approach. The new tracing code is also well-tested. I have one suggestion to refactor the new tracing wrapper to reduce code duplication, which should improve long-term maintainability.

[codecov]

Codecov Report

❌ Patch coverage is 92.59259% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.42%. Comparing base (66ac65a) to head (a31cf8c).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
block/components.go	33.33%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2993      +/-   ##
==========================================
+ Coverage   59.25%   59.42%   +0.17%     
==========================================
  Files         106      107       +1     
  Lines       10023    10075      +52     
==========================================
+ Hits         5939     5987      +48     
- Misses       3456     3458       +2     
- Partials      628      630       +2     

Flag	Coverage Δ
combined	59.42% <92.59%> (+0.17%)	⬆️

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.

[claude]

Claude finished @chatton's task in 2m 4s —— View job

---

Code Review Complete ✅

I've completed a comprehensive review of the tracing additions for the DA submitter. This is well-implemented, production-ready code that follows established patterns in the codebase. Below is my detailed analysis.

---

Summary

This PR adds OpenTelemetry tracing instrumentation to the DA submitter component by wrapping the DASubmitterAPI interface methods (SubmitHeaders and SubmitData). The implementation uses the decorator pattern consistently applied throughout the codebase and includes comprehensive test coverage.

Key Changes:

• Renamed daSubmitterAPI → DASubmitterAPI (exported interface to enable decorator pattern)
• Added tracedDASubmitter wrapper with OpenTelemetry spans in da_submitter_tracing.go
• Integrated tracing into both sync and aggregator node initialization paths in components.go
• Added 6 comprehensive unit tests covering success, error, and edge cases

---

1. Code Quality & Architecture ✅

Strengths:

• Consistent decorator pattern: Follows the same WithTracing* pattern used for sequencer, block producer, and syncer components
• Clean separation of concerns: Tracing logic isolated in dedicated files (da_submitter_tracing.go), not mixed with business logic
• Proper interface compliance: Uses compile-time verification var _ DASubmitterAPI = (*tracedDASubmitter)(nil) at da_submitter_tracing.go:17
• Idiomatic Go: Adheres to effective-go conventions with proper naming, error handling, and structure
• Zero-dependency pattern: The interface change supports the modular architecture described in CLAUDE.md

Integration Quality:

• Both NewSyncComponents (components.go:160-163) and NewAggregatorComponents (components.go:262-265) use identical conditional wrapping:

  var daSubmitter submitting.DASubmitterAPI = submitting.NewDASubmitter(...)
  if config.Instrumentation.IsTracingEnabled() {
      daSubmitter = submitting.WithTracingDASubmitter(daSubmitter)
  }

• Consistent with other tracing integrations (syncer at components.go:155-157, sequencer at components.go:213-215, executor at components.go:236-238)

Observations:

• Interface export (daSubmitterAPI → DASubmitterAPI) is necessary for the decorator pattern to work across package boundaries - good refactoring
• Tracer name "ev-node/da-submitter" aligns with naming convention used elsewhere in the codebase

Verdict: Excellent architecture that integrates seamlessly with existing patterns.

---

2. Error Handling & Resilience ✅

Strengths:

• Errors properly recorded with span.RecordError(err) and status set via span.SetStatus(codes.Error, err.Error()) (da_submitter_tracing.go:58-59, da_submitter_tracing.go:91-92)
• Error propagation is correct - wrapper doesn't swallow or modify errors
• Span cleanup guaranteed via defer span.End() (da_submitter_tracing.go:39, da_submitter_tracing.go:72)
• Context properly threaded through call chain

Best Practices:

• Follows OpenTelemetry semantic conventions for error recording
• Spans are ended in all code paths (success and error)
• No error suppression or unexpected error transformation

Verdict: Error handling follows OpenTelemetry best practices correctly.

---

3. Security ✅

Analysis:

• No sensitive data (credentials, keys, secrets) logged in span attributes
• Tracing captures only metadata: counts, byte sizes, and height ranges
• Height values (header.start_height, header.end_height, data.start_height, data.end_height) are safe to include
• Byte sizes (header.total_bytes, data.total_bytes) are safe metrics
• No input validation issues - wrapper delegates to inner implementation
• Signer passed through but not inspected or logged

Verdict: No security concerns identified. Safe for production use.

---

4. Performance & Resource Efficiency ✅

Strengths:

• Minimal overhead: Only adds span creation and simple attribute calculations
• Span attributes set efficiently using builder pattern
• No unnecessary allocations or blocking operations
• Byte size calculation is O(n) but trivial compared to actual DA submission work:

  var totalBytes int
  for _, h := range marshalledHeaders {
      totalBytes += len(h)
  }

Observations:

• Tracing is opt-in via config.Instrumentation.IsTracingEnabled(), so zero overhead when disabled
• The marshalled data is already in memory (passed as parameter), so no additional I/O
• Height range extraction is O(1) - just accesses first and last elements

Potential Consideration:

• Codecov reports 92.59% patch coverage with 4 lines missing in components.go. These are likely the conditional tracing wrapping lines (components.go:161-162, components.go:263-264), which would only be covered by integration tests with tracing enabled.

Verdict: Excellent performance characteristics with negligible overhead.

---

5. Testing & Reliability ⭐ Outstanding

Comprehensive Test Coverage:
The test suite in da_submitter_tracing_test.go includes 6 well-structured test cases:

1. ✅ TestTracedDASubmitter_SubmitHeaders_Success (lines 49-83)

   • Validates success path with multiple headers
   • Verifies span name, status, and all attributes
   • Tests height range tracking (100-102)

2. ✅ TestTracedDASubmitter_SubmitHeaders_Error (lines 85-109)

   • Ensures errors are properly recorded in spans
   • Validates error status code and description propagation

3. ✅ TestTracedDASubmitter_SubmitHeaders_Empty (lines 111-130)

   • Edge case: empty header array
   • Confirms graceful handling with zero counts

4. ✅ TestTracedDASubmitter_SubmitData_Success (lines 132-164)

   • Happy path for data submission
   • Validates data-specific attributes

5. ✅ TestTracedDASubmitter_SubmitData_Error (lines 166-190)

   • Error handling for data submission
   • Proper error code and description validation

6. ⚠️ Missing: TestTracedDASubmitter_SubmitData_Empty

   • Would mirror the headers empty test for completeness
   • Not critical since logic is identical, but improves test symmetry

Test Quality:

• Proper test isolation: Each test creates fresh SpanRecorder and TracerProvider via setupDASubmitterTrace helper (lines 40-47)
• Cleanup handled: t.Cleanup() ensures TracerProvider shutdown (line 44)
• Attribute validation: Uses helper testutil.RequireAttribute for asserting span attributes
• Mock implementation: Clean, focused mock (mockDASubmitterAPI, lines 21-38) with injectable behavior
• Edge case coverage: Tests empty arrays, multiple items, and error scenarios

Verdict: Exemplary test quality. This is production-ready code with excellent reliability guarantees.

---

6. Documentation & Developer Experience ✅

Strengths:

• Clear function comments: WithTracingDASubmitter at line 25-26
• Interface documentation: DASubmitterAPI comment at submitter.go:26-30 explains purpose
• Type comments: tracedDASubmitter documented at line 19
• Consistent naming makes code self-documenting
• Integration points clear with conditional wrapping logic

Code Readability:

• Variable names are descriptive (tracedDASubmitter, marshalledHeaders, etc.)
• Function structure is straightforward and easy to follow
• No complex logic or obscure patterns

Observations:

• The exported DASubmitterAPI interface enables reuse in other packages if needed
• Wrapping logic in components.go is identical in both paths, making it easy to understand and maintain

Minor Enhancement Opportunity:

• Could add package-level documentation explaining the tracing strategy, but this is optional given the code clarity

Verdict: Good developer experience with clear, maintainable code.

---

7. Observability Quality ⭐ Excellent

Span Attributes Captured:

For Headers (SubmitHeaders):

• header.count - Number of headers submitted
• header.total_bytes - Total marshalled size (excluding signatures)
• header.start_height - First header height (when non-empty)
• header.end_height - Last header height (when non-empty)

For Data (SubmitData):

• data.count - Number of data items submitted
• data.total_bytes - Total marshalled size (excluding signatures)
• data.start_height - First data height (when non-empty)
• data.end_height - Last data height (when non-empty)

Quality Assessment:

• Attribute naming follows conventions (<resource>.<metric> pattern)
• Metrics provide actionable observability into DA submission behavior
• Height ranges enable tracking submission lag, batching patterns, and sync progress
• Byte sizes help identify performance bottlenecks or oversized submissions
• Span names clearly identify operations: "DASubmitter.SubmitHeaders" and "DASubmitter.SubmitData"

Production Value:
These traces will enable operators to:

• Monitor DA submission latency and throughput
• Identify batching inefficiencies
• Track submission failures and error rates
• Correlate DA submission with blockchain height progression

Verdict: Excellent observability instrumentation that provides real production value.

---

Findings Summary

Critical Issues: 0 ✅

No critical issues found.

Major Issues: 0 ✅

No major issues found.

Minor Suggestions: 2

1. Optional: Add empty data test (da_submitter_tracing_test.go)

   • Currently missing TestTracedDASubmitter_SubmitData_Empty to mirror the headers test at line 111
   • Not critical since logic is identical to headers, but improves test symmetry
   • Add test →

2. Coverage gap in components.go (lines 161-162, 263-264)

   • Codecov shows 4 lines missing coverage in conditional tracing wrappers
   • These are only covered by integration tests with tracing enabled
   • Not actionable in this PR - would require adding integration tests with instrumentation enabled
   • Does not affect production safety

Positive Highlights 🌟

1. Consistent with codebase patterns - Follows established tracing patterns perfectly across sequencer, executor, syncer, and now DA submitter
2. Production-ready quality - Comprehensive tests, proper error handling, clean architecture
3. Zero breaking changes - Only exports interface; all existing code remains compatible
4. Excellent test coverage - 6 tests covering success, error, and edge cases with 92.59% patch coverage
5. Good observability - Captures meaningful metrics for monitoring DA submission behavior without exposing sensitive data
6. Minimal performance overhead - Only active when tracing enabled; negligible cost when active

---

Review Notes on Previous Feedback

Gemini's Suggestion (Code Duplication):
Gemini suggested extracting common tracing logic into a generic helper function using Go generics. The PR author (@chatton) correctly declined this in the review comment at da_submitter_tracing.go:97, noting:

"I think we can try and de-duplicate tracing logic after all the PRs are merged, this adds complexity without much value IMO."

Analysis:
I agree with this decision for several reasons:

1. Premature abstraction: The two methods have similar structure but different parameter signatures (SubmitHeaders has 4 params, SubmitData has 5)
2. Clarity over DRY: The current implementation is clear and easy to understand; the generic approach would add cognitive overhead
3. Future refactoring: Better to wait and see if more tracing wrappers emerge before creating abstractions
4. Consistency: Other tracing wrappers in the codebase (sequencer, executor) don't use generic helpers either

Recommendation: Keep the current implementation. Consider refactoring across all tracing wrappers together if duplication becomes problematic.

---

Final Recommendation

✅ APPROVE - This PR is ready to merge.

The implementation is clean, well-tested, and follows Go best practices and OpenTelemetry conventions. The tracing instrumentation provides valuable observability into DA submission behavior without introducing performance overhead or security risks. The code integrates seamlessly with the existing tracing infrastructure and maintains architectural consistency.

The only suggestions are optional enhancements that don't block merging. The missing test for empty data is not critical given the identical logic to headers, and the coverage gap in components.go would require integration test changes outside this PR's scope.

Excellent work maintaining consistency with the tracing infrastructure established in previous PRs! 🎉

---

Tasks

• Read all changed files
• Review code quality & architecture
• Review error handling & resilience
• Review security considerations
• Review performance & resource efficiency
• Review testing & reliability
• Review documentation & developer experience
• Provide final feedback and recommendations

---