[duplicate-code] Duplicate Code Pattern: Dual stdout/file logging pairs in cmd/root.go

[github-actions]

Part of duplicate code analysis: #3309

Summary

internal/cmd/root.go contains ~10 consecutive pairs where the same startup event is logged twice — once to stdout via log.Printf and again to the structured logger via logger.LogInfoMd / logger.LogWarn. This pattern spans approximately 20 lines and introduces a maintenance burden: any message change must be applied in two places, creating a risk of divergence.

Duplication Details

Pattern: log.Printf + logger.LogXxxMd pairs for identical startup messages

• Severity: Medium
• Occurrences: ~10 pairs (≈20 affected lines)
• Location: internal/cmd/root.go (lines 236–412)
• Code Sample:

// Pattern repeated ~10 times:
log.Printf("Guard policy override configured (source=%s)", policySource)
logger.LogInfoMd("startup", "Guard policy override configured (source=%s)", policySource)

log.Printf("MCP_GATEWAY_GUARDS_SINK_SERVER_IDS=%q", envSinkServerIDs)
logger.LogInfoMd("startup", "MCP_GATEWAY_GUARDS_SINK_SERVER_IDS=%q", envSinkServerIDs)

log.Printf("Guards sink server IDs configured for JSONL tag enrichment: %v", resolvedSinkServerIDs)
logger.LogInfoMd("startup", "Guards sink server IDs configured for JSONL tag enrichment: %v", resolvedSinkServerIDs)

log.Printf("Warning: guards sink server ID '%s' is not configured in mcpServers", sinkServerID)
logger.LogWarn("startup", "Guards sink server ID '%s' is not configured in mcpServers", sinkServerID)

log.Printf("Warning: failed to initialize tracing provider: %v", err)
logger.LogWarn("startup", "Failed to initialize tracing provider: %v", err)

log.Printf("Starting MCPG in ROUTED mode on %s", listenAddr)
logger.LogInfoMd("startup", "Starting in ROUTED mode on %s", listenAddr)

Impact Analysis

• Maintainability: Every message needs to be edited in two places; wording frequently diverges (e.g. log.Printf("Warning: ...") vs logger.LogWarn(...)).
• Bug Risk: Diverged messages make log correlation harder during incident investigation.
• Code Bloat: ~20 lines that could be ~10.

Refactoring Recommendations

1. Extend logger.LogInfoMd / logger.LogWarnMd to also echo to stdout (or add a tee mode) so callers need only one call. The MarkdownLogger already writes to both file and markdown — adding a stdout tee for startup messages would eliminate the pair.

2. Alternatively, wrap the pair in a helper such as:

   // internal/logger/startup.go
   func StartupInfo(format string, args ...interface{}) {
       log.Printf(format, args...)
       LogInfoMd("startup", format, args...)
   }

   Estimated effort: 1–2 hours. Callers in root.go become single-line.

3. At minimum, remove the redundant log.Printf calls where logger.LogInfoMd already writes a sufficiently descriptive message, since the file logger also writes to stdout via its fallback path.

Implementation Checklist

• Decide on approach (tee-mode vs startup helper vs remove redundant calls)
• Implement chosen approach in internal/logger/
• Update internal/cmd/root.go to use the new helper (~10 sites)
• Verify no startup messages are lost in tests
• Run make agent-finished

Parent Issue

See parent analysis report: #3309
Related to #3309

Generated by Duplicate Code Detector · ● 2.2M · ◷

• expires on Apr 14, 2026, 6:05 AM UTC

[github-actions]

🤖 This is an automated response from Repo Assist.

Good analysis in this issue — the log.Printf + logger.LogInfoMd dual-call pattern is a real maintenance burden. Looking at the code, I'd recommend Option 2 (startup helper) over the other approaches:

Why not Option 1 (tee mode in LogInfoMd): LogInfoMd is a general-purpose logger used well beyond startup. Adding stdout echo to it would pollute output during non-startup operations and would be a behavioural change affecting many call sites.

Why not Option 3 (just delete log.Printf): The log.Printf calls serve as a visible stdout safety net during early startup — before the file logger is confirmed working. If InitFileLogger fails, logger.LogInfoMd silently drops the message (the file logger's fallback path writes to a file, not stdout). The log.Printf lines at ~L130–150 in root.go are actually correct safety valves.

Option 2 works cleanly for the ~10 duplicate pairs at lines 236–412 (after the logger is confirmed running). A helper in internal/logger/startup.go:

// StartupInfo logs a startup message to both stdout and the file/markdown loggers.
func StartupInfo(format string, args ...interface{}) {
    log.Printf(format, args...)
    LogInfoMd("startup", format, args...)
}

func StartupWarn(format string, args ...interface{}) {
    log.Printf("Warning: "+format, args...)
    LogWarn("startup", format, args...)
}

This reduces each pair to a single call, keeps the stdout safety net, and centralises any future changes to startup message formatting (e.g. adding a [startup] prefix).

Generated by Repo Assist · ● 3.2M · ◷

To install this agentic workflow, run

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