fix(upstream): match the drift-issue signals label case-insensitively - #2619
Conversation
validateRecordedGitHubIssue already lowercases the owner and repo name before comparing them to the GitHub API response (mirroring GitHub's case-insensitive semantics), but compared the issue's "signals" label case-sensitively. A repo whose signals label is stored with different casing (e.g. "Signals") therefore failed validation, so the recorded drift issue was not recognized and a duplicate was filed. Compare the label lowercased, consistent with the owner/name checks in the same function.
|
Warning 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏸️ Gittensory review result - manual review recommendedReview updated: 2026-07-02 23:21:22 UTC
⏸️ Suggested Action - Manual Review Review summary
Review context
Contributor next steps
Signal definitions
🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2619 +/- ##
=======================================
Coverage 96.04% 96.04%
=======================================
Files 234 234
Lines 26209 26209
Branches 9510 9510
=======================================
Hits 25173 25173
Misses 425 425
Partials 611 611
🚀 New features to boost your workflow:
|
…tes (JSONbored#2442) The surface-lane orchestrator hard-closed any registry PR appending more than one surfaces[] entry, contradicting metagraphed's documented 2026-06 anti-farming policy that explicitly wants multi-entry PRs (confirmed live on PR JSONbored#2619, which the fix now resolves to merge instead of auto-close). RegistryLaneSpec gains an opt-in maxAppendedEntries cap (default preserves today's strict single-entry behavior for every other spec) and an opt-in duplicateKeyFields for cross-entry duplicate detection, closing a side effect where removing the entry cap also removed its incidental protection against same-PR duplicate submissions.
What
validateRecordedGitHubIssuerecognizes a previously-recorded upstream-drift issue by owner, repo name, fingerprint, and itssignalslabel. It already lowercases the owner and repo name before comparing them to the GitHub API response — but compared the label case-sensitively (=== "signals").Why it is a bug
GitHub labels are case-insensitive, and an applied label is normalized to the repo's existing label casing. If a repo's signals label is stored as e.g.
Signals, the case-sensitive check fails, the recorded drift issue is not recognized, and a duplicate issue is filed on the next run.This is an internal inconsistency: two lines up in the same function, the owner and repo-name comparisons are already case-insensitive (
parsedUrl.owner.toLowerCase() !== owner.toLowerCase()etc.), matching GitHub's semantics. The label check was the odd one out.Fix
Compare the label lowercased, consistent with the owner/name checks in the same function. One line.
Test
Signals(case-variant) scenario asserting the recorded issue is updated, not duplicated — this fails on the pre-fix code (it filed a duplicate) and passes after.[{}]) covering the optional-chain arm.No linked issue
No linked issue because this is a maintenance fix for an internal inconsistency (the same function already compares owner/repo case-insensitively); there is no tracking issue to link.