fix: Modify Evolve node logging to remove noise

[Manav-Aggarwal]

Overview

After #2416 was merged, the logging in evolve node included logs from the headerSyncService's p2p module, store module, and sync module via the go-header library. This caused a lot of noise in evolve node logs and shouldn't be enabled by default.

Also, made the creating empty block log back to INFO level so a user can see that evolve node is producing blocks when during no user activity and see what block height the node is at.

Also, fixes formatting issues with DA submission log.

https://www.loom.com/share/42b4be68bee74608b62cfdf07324a829?sid=4f889192-639b-477e-b5c6-fe941d6c7f70

Previously logging looked like this:

Logging now looks like this:

[github-actions]

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

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	✅ passed	✅ passed	Jul 25, 2025, 6:28 PM

[gemini-code-assist]

Summary of Changes

Hello @Manav-Aggarwal, 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 focuses on refining the logging output of the Evolve node to improve clarity and reduce unnecessary verbosity. My primary goal was to make the node's operational status more transparent to users by adjusting log levels and formatting, while suppressing verbose internal library logs that were cluttering the console.

Highlights

• Log Noise Reduction: I've suppressed excessive logging from the go-header library's header/store, header/sync, and header/p2p modules by setting their log level to FATAL. This significantly reduces the amount of noise in the Evolve node's console output.
• Improved Block Production Visibility: I've elevated the 'creating empty block' log message from DEBUG to INFO level. This allows users to easily track block production and the current block height, even when there's no user activity on the node.
• Enhanced DA Submission Logging: I've corrected the formatting of the 'successfully submitted to DA layer' log message. It now presents gasPrice and count more clearly within a single, formatted log string, improving readability.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

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 issue 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 or fill out our survey to provide feedback.

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 effectively reduces log noise by suppressing logs from external components and improves visibility by adjusting log levels. The changes are well-targeted. I've provided a few suggestions to further improve logging practices for consistency and to make the log level setup more robust and maintainable. Overall, this is a solid improvement.

[gemini-code-assist]

The repeated calls to logging.SetLogLevel can be made more maintainable and robust by using a loop. Also, the errors are currently ignored. While an error is unlikely with hardcoded values, it's safer to handle it. A panic is appropriate here since this is part of the initial setup, and a failure to set log levels should be considered a critical startup failure.

noisyComponents := []string{"header/store", "header/sync", "header/p2p"}
for _, component := range noisyComponents {
	if err := logging.SetLogLevel(component, "FATAL"); err != nil {
		// This is a developer error, so we should panic.
		panic(fmt.Sprintf("failed to set log level for %q: %s", component, err))
	}
}

[gemini-code-assist]

For consistency with other log statements in this file and for better machine-readability, it's best to use structured logging with key-value pairs instead of concatenating values into the message string.

Suggested change

	m.logger.Info("creating empty block, height: ", newHeight)
	m.logger.Info("creating empty block", "height", newHeight)

[gemini-code-assist]

This change moves away from structured logging by formatting all values into the message string. Structured logging with key-value pairs is generally preferred as it makes logs easier to parse, query, and analyze automatically. The previous implementation was better in this regard.

To maintain structured logging and improve consistency, consider using a static message and passing all dynamic values as key-value pairs.

Suggested change

	m.logger.Info(fmt.Sprintf("successfully submitted %s to DA layer with gasPrice %v and count %d", itemType, gasPrice, res.SubmittedCount))
	m.logger.Info("successfully submitted to DA layer", "itemType", itemType, "gasPrice", gasPrice, "count", res.SubmittedCount)

[tac0turtle]

I think we should do something to force debug mode on all in order to help with debugging. Something could be hidden in the logs and this would hide it

[Manav-Aggarwal]

Modified it to only supress this by default and enable them if debug logging is enabled in 3243175

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.23%. Comparing base (d89b796) to head (3243175).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2496      +/-   ##
==========================================
+ Coverage   73.18%   73.23%   +0.04%     
==========================================
  Files          69       69              
  Lines        6564     6568       +4     
==========================================
+ Hits         4804     4810       +6     
+ Misses       1363     1361       -2     
  Partials      397      397              

Flag	Coverage Δ
combined	73.23% <100.00%> (+0.04%)	⬆️

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 @Manav-Aggarwal's task —— View job

---

Code Review for PR #2496

I'll review this pull request for code quality, potential issues, performance, security, and test coverage.

Todo List:

• Read and analyze changed files
• Review code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Examine security concerns
• Evaluate test coverage needs
• Provide comprehensive feedback

Analysis Summary:
The PR makes 3 types of changes across 3 files:

1. pkg/cmd/run_node.go: Conditionally suppress noisy external logs (header/store, header/sync, header/p2p) only when not in debug mode
2. block/manager.go: Promote "creating empty block" from DEBUG to INFO level and consolidate block creation logs
3. block/submitter.go: Change DA submission from structured to formatted string logging

---

Review Findings

✅ Code Quality & Best Practices

Good Changes:

• Smart Debug Handling: The conditional suppression in pkg/cmd/run_node.go:71-75 is well-designed. It addresses @tac0turtle's concern by preserving debug logs when explicitly enabled while reducing noise by default.
• Better UX: Promoting "creating empty block" to INFO level (block/manager.go:659) improves user visibility of node activity.
• Log Consolidation: Combining block creation logs in block/manager.go:668 reduces verbosity.

Areas for Improvement:

• Inconsistent Logging Style: The change in block/submitter.go:128 moves away from structured logging (key-value pairs) to formatted strings, which is inconsistent with Go logging best practices and the existing codebase.
• Error Handling: The _ = logging.SetLogLevel(...) calls ignore potential errors. While unlikely with hardcoded values, it's safer to handle them during startup.

Specific Recommendations:

1. block/submitter.go:128 - Revert to structured logging for consistency:

   // Current (formatted string):
   m.logger.Info(fmt.Sprintf("successfully submitted %s to DA layer with gasPrice %v and count %d", itemType, gasPrice, res.SubmittedCount))
   
   // Recommended (structured):
   m.logger.Info("successfully submitted to DA layer", "itemType", itemType, "gasPrice", gasPrice, "count", res.SubmittedCount)

2. pkg/cmd/run_node.go:72-74 - Add error handling and use a loop for maintainability:

   noisyComponents := []string{"header/store", "header/sync", "header/p2p"}
   for _, component := range noisyComponents {
       if err := logging.SetLogLevel(component, "FATAL"); err != nil {
           return logging.Logger("main") // or handle appropriately
       }
   }

3. block/manager.go:659 - Consider structured logging for consistency:

   // Current:
   m.logger.Info("creating empty block, height: ", newHeight)
   
   // Recommended:
   m.logger.Info("creating empty block", "height", newHeight)

✅ Potential Bugs & Issues

No Critical Issues Found, but minor concerns:

• Silent Failures: Ignored errors from SetLogLevel could mask configuration issues
• String Concatenation: The "creating empty block, height: " + newHeight pattern in block/manager.go:659 mixes styles

✅ Performance Considerations

No Performance Impact:

• Log level changes are configuration-time operations
• Reduced logging volume may slightly improve performance under high load
• String formatting in DA logs has negligible impact given the context

✅ Security Concerns

No Security Issues:

• Changes only affect logging configuration and output format
• No exposure of sensitive data in log changes
• Log suppression doesn't hide security-relevant information

✅ Test Coverage

No Test Changes Needed:

• These are logging configuration changes that don't affect business logic
• Existing tests should continue to pass
• Consider adding integration tests for log level behavior if comprehensive logging tests don't exist

---

Summary & Recommendation

Overall Assessment: ✅ APPROVE with minor suggestions

The PR successfully addresses the noise problem described in the issue. The conditional debug handling is particularly well thought out and addresses reviewer concerns about hiding important debug information.

Key Strengths:

• Solves the immediate noise problem effectively
• Preserves debug logs when explicitly enabled
• Improves user experience with better block production visibility

Suggested Improvements (non-blocking):

1. Revert to structured logging in block/submitter.go for consistency
2. Add error handling for SetLogLevel calls
3. Consider using structured logging throughout for consistency

The changes align well with the project's logging architecture and don't introduce any functional risks.

---