[duplicate-code] Global Logger Initialization Wrapper Boilerplate

[github-actions]

🔍 Duplicate Code Pattern: Global Logger Initialization Wrappers

Part of duplicate code analysis: #929

Summary

The internal/logger/global_helpers.go and internal/logger/tools_logger.go files contain 10 nearly identical wrapper functions for initializing and closing global loggers. While generic helper functions exist, each logger type requires its own wrapper, creating boilerplate code.

Duplication Details

Pattern: Init/Close Wrapper Functions

• Severity: Low

• Occurrences: 10 wrapper functions (5 pairs of init/close)

• Locations:

  • internal/logger/global_helpers.go lines 88-125 (FileLogger, JSONLLogger, MarkdownLogger, ServerFileLogger wrappers)
  • internal/logger/tools_logger.go lines 153-160 (ToolsLogger wrappers)

• Code Sample (Pattern repeated 5 times):

  // FileLogger wrappers
  func initGlobalFileLogger(logger *FileLogger) {
      initGlobalLogger(&globalLoggerMu, &globalFileLogger, logger)
  }
  
  func closeGlobalFileLogger() error {
      return closeGlobalLogger(&globalLoggerMu, &globalFileLogger)
  }
  
  // JSONLLogger wrappers
  func initGlobalJSONLLogger(logger *JSONLLogger) {
      initGlobalLogger(&globalJSONLMu, &globalJSONLLogger, logger)
  }
  
  func closeGlobalJSONLLogger() error {
      return closeGlobalLogger(&globalJSONLMu, &globalJSONLLogger)
  }
  
  // MarkdownLogger wrappers
  func initGlobalMarkdownLogger(logger *MarkdownLogger) {
      initGlobalLogger(&globalMarkdownMu, &globalMarkdownLogger, logger)
  }
  
  func closeGlobalMarkdownLogger() error {
      return closeGlobalLogger(&globalMarkdownMu, &globalMarkdownLogger)
  }
  
  // ... and 2 more pairs (ServerFileLogger, ToolsLogger)

Impact Analysis

• Maintainability: Low impact - Generic helpers already abstract the core logic
• Bug Risk: Very Low - Functions are simple wrappers with minimal logic
• Code Bloat: ~20 lines of boilerplate wrapper functions
• Benefit of Generic Helpers: The codebase already uses generic initGlobalLogger and closeGlobalLogger functions, which is the RIGHT approach

Assessment

This pattern is ACCEPTABLE and low-priority for refactoring because:

1. The generic helper functions (initGlobalLogger, closeGlobalLogger) already exist and abstract the complex logic
2. The wrappers serve as a stable API layer that maintains backward compatibility
3. Each wrapper is simple (2-3 lines) and easy to maintain
4. The pattern follows Go idioms for type-specific function wrappers
5. Removing wrappers would expose generic functions to callers, reducing type safety

Recommendations

Option 1: Keep Current Design (Recommended)

• Estimated effort: 0 hours (no change)
• Benefits:
  • Maintains backward compatibility
  • Type-safe API for each logger
  • Clear separation between public and internal interfaces
  • Generic helpers already prevent duplication of complex logic
• Rationale: The current design is intentional and follows best practices for Go generics usage

Option 2: Direct Generic Function Calls

• Remove wrappers and call generic functions directly
• Estimated effort: 1-2 hours
• Benefits: Reduces line count by ~20 lines
• Trade-offs:
  • Breaks backward compatibility
  • Exposes internal generic functions
  • Reduces type safety
  • Harder to change initialization logic per-logger-type in future
• Not recommended - Cost exceeds benefit

Implementation Checklist

• Review duplication findings
• Assess pattern as acceptable
• Optional: Add documentation explaining the wrapper pattern
• No code changes recommended

Conclusion

This duplication is intentional and acceptable. The generic helper functions already eliminated the meaningful duplication. The wrappers provide a stable, type-safe API while maintaining flexibility for future per-logger customization.

Priority: LOW - No action needed

Parent Issue

See parent analysis report: #929
Related to #929

AI generated by Duplicate Code Detector

• expires on Feb 21, 2026, 10:12 AM UTC