Investigate why duplicate issues were created

[rviscomi]

The update-issues.ts script is failing to recognize certain existing feature issues and is improperly creating duplicates for them during its automated runs.

During a recent run, the script processed dozens of features as if they were brand new and created new issues, even though valid, open issues with the correct feature label and web-features ID already existed in the repository.

Examples of Duplicated Issues:

• <link rel="prefetch">: The script created a new issue <link rel="prefetch"> #591, despite issue <link rel="prefetch"> #306 already being open.
• WebNN: The script created a new issue WebNN #844, despite issue WebNN #322 already being open.
• KHR_parallel_shader_compile WebGL extension: The script created a new issue KHR_parallel_shader_compile WebGL extension #599, despite issue KHR_parallel_shader_compile WebGL extension #104 already being open.
• background-attachment: The script created background-attachment #592, despite background-attachment #498 existing.

Expected Behavior:
The script should detect that these features already have an associated open issue, log that they are "up-to-date", and skip creating a new issue.

[rviscomi]

I had Gemini investigate what happened and it came up with this report, which seems sound to me

---

I have pinpointed the root cause of the duplicate issue creation.

The Root Cause

The duplication was caused by an incomplete openIssues map during the initial script execution on May 27th. Specifically, the script failed to fetch Page 3 of the existing issues, which contained dozens of features including link-rel-prefetch (#306) and WebNN (#322).

1. Pagination Failure: Logs from that run show that the script processed features shipped in 2006 (like link-rel-prefetch) just one second after starting. This is physically impossible if it had successfully fetched all 350+ issues (which takes several seconds across 4 pages).
2. Silent Errors: The script uses ThrottlingOctokit but does not provide a logger. Consequently, any "Secondary Rate Limit" warnings or "Request quota exhausted" messages from Octokit were silently swallowed.
3. Parameter Mismatch: The script passes labels: ["feature"] (an array) to listForRepo. While Octokit usually handles this, passing an array to a parameter the API expects as a string is known to cause inconsistent pagination behavior in some environments (especially with cursor-based pagination which GitHub uses for large result sets). On May 27th, this likely caused the API to return an empty response or miss the next link for Page 3.
4. Partial Success: The script did successfully fetch Page 4 (the oldest issues like datalist), which is why it reported those as "up-to-date". This indicates a non-linear pagination failure where Page 3 was skipped or returned empty.

The Fix

The fix is to make the issue-fetching logic robust and visible:

1. Use String Parameters: Change labels: ["feature"] to labels: "feature" to ensure standard API behavior during pagination.
2. Refactor Pagination: Use the simpler octokit.paginate instead of the manual iterator to let Octokit handle the page merging more reliably.
3. Enable Logging: Pass a logger to Octokit so that throttling warnings and API errors are actually visible in the GitHub Action logs.
4. Retry on Secondary Limits: Update the throttling configuration to retry on secondary rate limits instead of just logging a (previously invisible) warning and failing.

Refined Plan

1. Modify iterateIssues: Refactor to use octokit.paginate and string labels.
2. Update Octokit Config: Add log: console and enable retries for secondary rate limits.
3. Add Visibility Logs: Log the number of issues fetched and matched to ensure the map is complete before the main loop starts.

[rviscomi]

Everything should be back to normal now.

The GraphQL changes in #849 fixed the GH action so it should find all of the existing issues properly. I've also closed all of the duplicate issues so that they don't interfere with the JSON manifest.

37 of the duplicate issues did end up getting some upvotes, but no comments. None got more than 3 upvotes. If we really really wanted to avoid wasting these upvotes, we could still include them in their canonical feature's total count, but I didn't bother.