[duplicate-code] Duplicate Code Pattern: getDefault* Env-Wrapper Function Proliferation in cmd/flags

[github-actions]

Part of duplicate code analysis: #3827

Summary

Across three internal/cmd/flags_*.go files, 13 trivially similar getDefault* functions exist, each being a 3-line wrapper that calls envutil.GetEnvString, envutil.GetEnvInt, or envutil.GetEnvBool with a hardcoded env-var name and a default value. Nine of the thirteen are structurally identical single-return wrappers.

Duplication Details

Pattern: getDefault* env-var wrapper functions

• Severity: Low

• Occurrences: 13 functions across 3 files

• Locations:

  • internal/cmd/flags_logging.go (lines 35–56): getDefaultLogDir, getDefaultPayloadDir, getDefaultPayloadPathPrefix, getDefaultPayloadSizeThreshold
  • internal/cmd/flags_difc.go (lines 58–92): getDefaultAllowOnlyScopePublic, getDefaultDIFCSinkServerIDs, getDefaultGuardPolicyJSON, getDefaultAllowOnlyOwner, getDefaultAllowOnlyRepo, getDefaultAllowOnlyMinIntegrity
  • internal/cmd/flags_tracing.go (lines 31–40): getDefaultOTLPEndpoint, getDefaultOTLPServiceName

• Code Sample (9 of 13 functions look like this):

  // getDefaultPayloadDir returns the default payload directory, checking MCP_GATEWAY_PAYLOAD_DIR
  // environment variable first, then falling back to the hardcoded default
  func getDefaultPayloadDir() string {
      return envutil.GetEnvString("MCP_GATEWAY_PAYLOAD_DIR", config.DefaultPayloadDir)
  }

Note: getDefaultDIFCMode is a justified exception — it includes validation logic beyond a simple env lookup.

Impact Analysis

• Maintainability: Low risk day-to-day, but adding new flags continues to grow the file with boilerplate. The docstring and function naming convention is inconsistently applied.
• Bug Risk: Low — each function is independent and correct.
• Code Bloat: ~30 lines of highly repetitive 3-line functions.

Refactoring Recommendations

1. Inline the calls directly in the init() / RegisterFlag block

   Since these functions are only called once (as default-value arguments in flag registration), they can be inlined:

   // Before
   cmd.Flags().StringVar(&payloadDir, "payload-dir", getDefaultPayloadDir(), "...")
   
   // After (inline)
   cmd.Flags().StringVar(&payloadDir, "payload-dir", envutil.GetEnvString("MCP_GATEWAY_PAYLOAD_DIR", config.DefaultPayloadDir), "...")

   This removes the need for the 3-line helper entirely. The env-var name is documented in AGENTS.md and README.md, so discoverability is not a concern.

2. Alternative: centralise defaults in a flagDefaults struct

   If you prefer named defaults for testability, define them once:

   var flagDefaults = struct {
       logDir    func() string
       payloadDir func() string
   }{
       logDir:    func() string { return envutil.GetEnvString("MCP_GATEWAY_LOG_DIR", config.DefaultLogDir) },
       payloadDir: func() string { return envutil.GetEnvString("MCP_GATEWAY_PAYLOAD_DIR", config.DefaultPayloadDir) },
   }

   This keeps the logic in one place and makes testing easier.

Implementation Checklist

• Decide between inlining vs. centralising defaults
• Remove the 9 trivial getDefault* wrappers, replacing with inline envutil.Get* calls
• Keep getDefaultDIFCMode as-is (it contains validation logic)
• Run make lint and make test to confirm no regressions

Parent Issue

See parent analysis report: #3827
Related to #3827

Generated by Duplicate Code Detector · ● 1.7M · ◷

• expires on Apr 22, 2026, 6:13 AM UTC

[github-actions]

🤖 This is an automated response from Repo Assist.

The analysis is accurate — these 13 functions are trivial 1-liner wrappers. However, I'd lean against the "inline everything" recommendation for a few reasons:

1. Testability: The new PR [test] Add tests for cmd.newProxyCmd and cmd.detectGuardWasm #3839 already tests TestNewProxyCmd_DefaultFlagValues by calling getDefaultLogDir() et al. directly. Inlining would make those tests harder to write without mocking env vars.

2. Discoverability: Having named functions like getDefaultPayloadDir() makes it easy to search the codebase for "who reads MCP_GATEWAY_PAYLOAD_DIR". Inline calls are harder to grep.

3. The boilerplate cost is low: Each function is 3 lines; the files are not growing fast.

The more realistic risk is inconsistency — some functions have docstrings, others don't; naming conventions drift. A lighter-weight fix is just to standardize the doc comments and leave the functions in place.

If the goal is truly to reduce LOC, the flagDefaults struct alternative in the issue is cleaner than inlining — it centralizes all defaults in one place without breaking discoverability. Worth considering if new flags keep getting added.

Overall: low priority; no action needed unless a maintainer specifically wants to reduce boilerplate.

Warning

⚠️ Firewall blocked 6 domains

The following domains were blocked by the firewall during workflow execution:

• go.opentelemetry.io
• go.yaml.in
• golang.org
• google.golang.org
• gopkg.in
• proxy.golang.org

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "go.opentelemetry.io"
    - "go.yaml.in"
    - "golang.org"
    - "google.golang.org"
    - "gopkg.in"
    - "proxy.golang.org"

See Network Configuration for more information.

Generated by Repo Assist · ● 5M · ◷

To install this agentic workflow, run

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