Repository navigation
security-issue-import: Step 2 thread-ID de-dup misses tracked threads (backtick-wrapped ids not found by search) #1730
Description
Step 2 of security-issue-import (existing-tracker-dedup.md) batches Gmail threadIds into gh search issues '"<id>" OR …' --match body. On an adopter tracker, all five batches (26 ids) returned zero hits, including threads whose ids verifiably appear in tracker bodies.
The Security mailing list thread field stores them backtick-wrapped (Gmail thread `1a0…` ), the shape outcomes/mailing-thread.md prescribes. GitHub issue search appears not to tokenise a hex id inside backticks, so every tracked thread looks untracked, and only the later title search / manual review prevents re-imports.
Suggested fix: match on the PonyMail permalink or root Message-ID (also recorded), or fetch candidate bodies and grep locally; add a regression check that a known-tracked id is found.
🤖 Generated with Claude Code
Activity
KatalKavya96 commentedon Oct 21, 2026
@potiuk,
The fix for this issue has been implemented and submitted for review.
#1750
GitHub issue search was missing certain thread IDs enclosed in Markdown backticks. The updated import workflow now performs deterministic matching against the authoritative mailing-thread field using a bounded, authorised tracker index.
The change includes regression tests and updated evaluation fixtures. All repository hooks passed, and the Step 2 model evaluation passed 4/4 cases, including the original backtick-wrapped ID scenario.
Thanks!