[duplicate-code] Update issue/pr scripts duplicate the same wrapper logic

[github-actions]

🔍 Duplicate Code Detected: Update issue/PR wrappers

Analysis of commit 6c88dce

Assignee: @copilot

Summary

pkg/workflow/js/update_issue.cjs and pkg/workflow/js/update_pull_request.cjs both define the same wrapper pipeline around runUpdateWorkflow: identical context guards, number extractors, staged preview rendering, summary generators, and main() invocations that only differ in strings plus one extra body-operation branch for PRs. Each file is ~150 lines, so the shared runner still leaves a lot of duplicated boilerplate that must be kept in sync manually.

Duplication Details

Pattern: Duplicated wrapper functions for update_issue vs update_pull_request

• Severity: Medium
• Occurrences: 2 large files (>100 lines each)
• Locations:
  • pkg/workflow/js/update_issue.cjs:6-100
  • pkg/workflow/js/update_pull_request.cjs:6-153
• Code Sample:

async function main() {
  return await runUpdateWorkflow({
    itemType: "update_issue",
    displayName: "issue",
    displayNamePlural: "issues",
    numberField: "issue_number",
    outputNumberKey: "issue_number",
    outputUrlKey: "issue_url",
    isValidContext: isIssueContext,
    getContextNumber: getIssueNumber,
    supportsStatus: true,
    supportsOperation: false,
    renderStagedItem,
    executeUpdate: executeIssueUpdate,
    getSummaryLine,
  });
}

The PR variant is the same block with swapped strings plus a different supportsOperation flag, and both files also carry nearly identical renderStagedItem/getSummaryLine implementations.

Impact Analysis

• Maintainability: Any shared UX change (e.g., staging summary format, AI footer wording) must be edited in both files; they can easily drift like the missing AI footer for issues.
• Bug Risk: Fixes to context detection or permission logging in one script may never reach the other, producing inconsistent runtime behavior.
• Code Bloat: Adds ~250 lines of boilerplate that obscure the real differences (event matcher + API call) and makes future update_* scripts harder to add without copying.

Refactoring Recommendations

1. Create a declarative metadata table for update entities
   • Export an array/object describing each entity (event names, summary template, flags) and let a single generic script feed it into runUpdateWorkflow.
   • Estimated effort: 4-5 hours to design the config and port both scripts.
   • Benefits: New update types can be added by data only; staging and summary formatting stay unified.
2. Split unique logic into strategy hooks
   • Keep a shared runner but pass only the unique pieces (executeUpdate, optional body-operation handler) from small modules. Shared code (context guards, staged previews, summary text) lives in one place.
   • Estimated effort: 2-3 hours once metadata exists.
   • Benefits: Ensures AI footer / operation handling bugs get fixed everywhere simultaneously.

Implementation Checklist

• Review duplication findings
• Prioritize refactoring tasks
• Create refactoring plan
• Implement changes
• Update tests
• Verify no functionality broken

Analysis Metadata

• Analyzed Files: 2
• Detection Method: Serena semantic code analysis (file inspection + pattern search)
• Commit: 6c88dce
• Analysis Date: 2025-11-29T21:05:59Z

AI generated by Duplicate Code Detector