[duplicate-code] Duplicate Code: update-entity parser wrappers in pkg/workflow

[github-actions]

🔍 Duplicate Code Detected: Update-Entity Parser Wrappers

Analysis of commit 2b4a6df88d5ea6216b577a0af184f9cecff96771

Assignee: @copilot

Duplicate parser wrapper report - 2026-08-09

Summary

Four workflow update parser methods are thin wrappers around parseUpdateEntityConfigTyped with the same control flow, logging pattern, and callback structure. The meaningful differences are mostly declarative field lists and a small amount of post-processing.

Duplication Details

Pattern: parseUpdateEntityConfigTyped wrappers

• Severity: Medium
• Occurrences: 4
• Locations:
  • pkg/workflow/update_issue.go (lines 25-44)
  • pkg/workflow/update_discussion.go (lines 23-45)
  • pkg/workflow/update_pull_request.go (lines 24-46)
  • pkg/workflow/update_release.go (lines 16-24)
• Code Sample:

return parseUpdateEntityConfigTyped(c, outputMap,
    UpdateEntityIssue, "update-issue", updateIssueLog,
    func(cfg *UpdateIssuesConfig) []UpdateEntityFieldSpec {
        return []UpdateEntityFieldSpec{
            {Name: "status", Mode: FieldParsingKeyExistence, Dest: &cfg.Status},
            {Name: "title", Mode: FieldParsingKeyExistence, Dest: &cfg.Title},
            {Name: "body", Mode: FieldParsingBoolValue, Dest: &cfg.Body},
            {Name: "footer", Mode: FieldParsingTemplatableBool, StringDest: &cfg.Footer},
        }
    }, func(configMap map[string]any, cfg *UpdateIssuesConfig) { ... })

Impact Analysis

• Maintainability: parser changes have to be applied in four separate wrappers.
• Bug Risk: field-mode drift is easy to introduce when one handler evolves and the others do not.
• Code Bloat: the repeated wrapper scaffolding makes it harder to see the actual per-entity schema differences.

Refactoring Recommendations

1. Introduce a declarative update-parser spec

   • Extract entity type, output key, logger, field specs, and post-processing into a shared table keyed by update entity type.
   • Estimated effort: 2-4 hours
   • Benefits: one parser entry point, less drift in field parsing semantics.

2. Factor reusable field-spec fragments

   • Reuse shared fragments for title, body, footer, labels, and filter-related fields instead of rebuilding slices inline.
   • Estimated effort: 1-2 hours
   • Benefits: smaller diffs when adding or changing common update behavior.

Implementation Checklist

• Review the four existing wrappers and enumerate their real differences
• Define a shared spec type for update parser registration
• Migrate issue, discussion, pull request, and release parsers to the shared path
• Keep current logging and backwards-compatibility behavior intact
• Update or add parser-focused unit coverage

Analysis Metadata

• Analyzed Files: targeted review of 14 files within 1,599 eligible changed .go/.cjs paths in the shallow initial-import snapshot
• Detection Method: Serena semantic code analysis and targeted source inspection
• Commit: 2b4a6df88d5ea6216b577a0af184f9cecff96771
• Analysis Date: 2026-08-09T22:01:37Z

Generated by 🔍 Duplicate Code Detector · gpt54 · 103.8 AIC · ⊞ 12.8K · ◷

• expires on Aug 11, 2026, 2:04 PM UTC-08:00