[duplicate-code] Duplicate Code Pattern: Log level dispatch quartet repeated across 3 logger façades

[github-actions]

Part of duplicate code analysis: #3685

Summary

The LogInfo / LogWarn / LogError / LogDebug level-dispatch quartet appears three times in the logger package, once per logging façade (file, markdown, per-server). Each set of four functions follows the same structural pattern: a public one-liner that calls a private logWithXxx helper at the appropriate level constant.

Duplication Details

Pattern: 4-function level-dispatch quartet (×3 façades)

• Severity: Medium
• Occurrences: 3 complete sets (12 functions total)
• Locations:
  • internal/logger/file_logger.go lines 122–140 — LogInfo / LogWarn / LogError / LogDebug calling logWithLevel
  • internal/logger/markdown_logger.go lines 197–214 — LogInfoMd / LogWarnMd / LogErrorMd / LogDebugMd calling logWithMarkdownLevel
  • internal/logger/server_file_logger.go lines 158–176 — LogInfoWithServer / LogWarnWithServer / LogErrorWithServer / LogDebugWithServer calling logWithLevelAndServer
• Code Sample (shape is identical across all three files):

  // LogInfo logs an informational message
  func LogInfo(category, format string, args ...interface{}) {
      logWithLevel(LogLevelInfo, category, format, args...)
  }
  // LogWarn logs a warning message
  func LogWarn(category, format string, args ...interface{}) {
      logWithLevel(LogLevelWarn, category, format, args...)
  }
  // (LogError and LogDebug follow the same pattern)

Impact Analysis

• Maintainability: Adding a new LogLevel constant requires updating the quartet in all three files. The existing logFuncs map (file_logger.go:147) partially mitigates this for the inner dispatch, but the public wrappers still need manual updates.
• Bug Risk: Low for existing levels; medium for new level additions (easy to miss one façade).
• Code Bloat: ~36 lines of structurally identical one-liner wrappers.

Refactoring Recommendations

1. Code-generate the wrappers using go generate + a small template. Each façade provides only its inner logWithXxx function; the four public wrappers are emitted by generate. This is the highest-fidelity option if new levels are anticipated.

2. Consolidate into a LogFacade struct with a single variadic Log(level, ...) method, replacing the four typed wrappers. Callers that currently rely on LogInfo(...) continue to work via thin aliases. This reduces the public surface while centralising level dispatch.

3. Accept the pattern (lowest effort) — logFuncs already prevents switch-on-level duplication inside each helper; the remaining four wrappers per façade are very small. Document explicitly that adding a LogLevel requires updating all three façades.

Implementation Checklist

• Review duplication findings
• Decide on refactoring strategy (code-gen vs. LogFacade struct vs. document)
• If refactoring: update all callers of the public log functions
• Run make agent-finished to verify no regressions

Parent Issue

See parent analysis report: #3685
Related to #3685

Generated by Duplicate Code Detector · ● 1.6M · ◷

• expires on Apr 20, 2026, 6:16 AM UTC

[github-actions]

🤖 This is an automated response from Repo Assist.

I'd recommend Option 3 — accept the pattern here, with one small documentation improvement.

The three façades are intentionally asymmetric at the call site:

• LogInfo(category, format, args...) — unified file logger
• LogInfoMd(category, format, args...) — markdown logger
• LogInfoWithServer(serverID, category, format, args...) — per-server logger (extra serverID parameter)

Because the signatures differ (especially WithServer), they can't share a common interface without adapting callers. A LogFacade struct would reduce the duplication in theory but would require touching every call site in cmd/, server/, etc., and the go generate approach adds tooling overhead for a pattern that's unlikely to grow new levels.

The logFuncs map inside file_logger.go already prevents the real duplication risk (the level-to-string dispatch); what remains are 12 tiny one-liners. Given that adding a new LogLevel is rare and the files are short, the practical risk is low.

Suggested documentation fix (low effort, zero risk): add a comment to the logFuncs map or to AGENTS.md noting that the three façade files mirror each other's level wrappers, so any new level needs to be added to all three. That's the whole safeguard needed.

Generated by Repo Assist · ● 2.7M · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@851905c06e905bf362a9f6cc54f912e3df747d55

[lpcox]

Already addressed by existing logFuncs map in global_helpers.go — no further dedup needed.