* feat(ci): auto-close duplicate issues
Signed-off-by: Pat Sukprasert <pat.sukprasert@databricks.com>
* fix(ci): improve duplicate candidate recall
Signed-off-by: Pat Sukprasert <pat.sukprasert@databricks.com>
* fix: search duplicate issues by terms
Signed-off-by: Pat Sukprasert <pat.sukprasert@databricks.com>
* fix: harden duplicate issue closure
Signed-off-by: Pat Sukprasert <pat.sukprasert@databricks.com>
* fix: preserve duplicate triage overrides
Signed-off-by: Pat Sukprasert <pat.sukprasert@databricks.com>
* feat: gate duplicate issue closure
Signed-off-by: Pat Sukprasert <pat.sukprasert@databricks.com>
* perf(triage): rank duplicates over the whole issue corpus
Keyword search was the real bottleneck on duplicate recall: across 11
recent issues it returned zero candidates for three of them and two or
fewer for four more, so the correct match never reached the LLM at all
(#4027's match was never retrieved). A query-dependent candidate set also
made IDF — and therefore the closure threshold — depend on what search
happened to return, so the same pair scored anywhere from 0.454 to 0.558.
Rank every issue in the repository instead. One `gh issue list` call
replaces the four search queries, fetches all 729 issues (open and
closed, so long-fixed reports stay discoverable) in ~10s, and scoring is
35ms. The candidate block sent to the model stays capped at 10.
Also strip code fences and traceback lines before tokenizing. Crash
reports share a long click/cli traceback template that scored unrelated
crashes at 0.79 cosine — above the close floor — which would have made
(DuplicateOptionError). Stripping drops that pair to 0.078 while genuine
repeats hold (#3359 -> #2993 stays at 0.956).
Co-authored-by: Isaac
Signed-off-by: Pat Sukprasert <pattara.sk127@gmail.com>
---------
Signed-off-by: Pat Sukprasert <pat.sukprasert@databricks.com>
Signed-off-by: Pat Sukprasert <pattara.sk127@gmail.com>
Pat Sukprasert
29a97938de