Skip to content

fix(review): add missing duplicationDelta to REES_ANALYZER_NAMES - #5861

Closed
lourincedaging0-commits wants to merge 1 commit into
JSONbored:mainfrom
lourincedaging0-commits:fix-rees-duplication-delta
Closed

fix(review): add missing duplicationDelta to REES_ANALYZER_NAMES#5861
lourincedaging0-commits wants to merge 1 commit into
JSONbored:mainfrom
lourincedaging0-commits:fix-rees-duplication-delta

Conversation

@lourincedaging0-commits

Copy link
Copy Markdown
Contributor

Summary

REES_ANALYZER_NAMES in src/review/enrichment-analyzer-names.ts is the canonical single-source-of-truth list that validates both the operator REES_ANALYZERS env list and per-repo .loopover.yml review.enrichment toggles. It listed 56 analyzers, but the generated review-enrichment/analyzer-metadata.json registry (also surfaced via the MCP taxonomy resource) defines 57"duplicationDelta" (defaultEnabled: true, sitting right next to "duplication") was the one missing entry.

Two concrete, reachable breakages in src/review/enrichment-wire.ts as a result:

  • resolveReesAnalyzers rejected "duplicationDelta" as an "invalid" analyzer name for any self-host operator who put it in an explicit REES_ANALYZERS env list.
  • resolveEnrichmentAnalyzerSelection could never let a repo owner toggle duplicationDelta per-repo via .loopover.yml review.enrichment.

Fix

Add "duplicationDelta" to the list, immediately after "duplication" (matching the registry's own ordering), so the canonical list is once again an exact match for the metadata registry.

Tests

Adds a parity block to test/unit/enrichment-analyzers-taxonomy.test.ts:

  • REES_ANALYZER_NAMES covers exactly the analyzers the metadata registry defines — compared as sets against the registry (the source of truth), not a hardcoded count, so a newly-added analyzer can't silently drift the two apart again.
  • Regression assertion that both duplication and duplicationDelta are present.
  • A no-duplicate-entries guard.

100% patch coverage on the touched module locally.

Closes #5839

REES_ANALYZER_NAMES in enrichment-analyzer-names.ts is the canonical list that
validates operator `REES_ANALYZERS` env entries and per-repo `.loopover.yml`
`review.enrichment` toggles. It listed 56 analyzers but the generated
analyzer-metadata.json registry defines 57 — `duplicationDelta` (right next to
`duplication`) was the one gap. As a result resolveReesAnalyzers rejected
`duplicationDelta` as "invalid" for operators who listed it explicitly, and
resolveEnrichmentAnalyzerSelection could never honor a per-repo toggle for it.

Add the missing entry so the list exactly matches the metadata registry, and
add a parity test asserting REES_ANALYZER_NAMES and the registry stay in sync
(set equality against the registry as source of truth, so a future analyzer
can't silently drift the two apart), plus a regression assertion for
duplicationDelta and a no-duplicates check.
@superagent-security

Copy link
Copy Markdown
Contributor

Superagent didn't find any vulnerabilities or security issues in this PR.

@loopover-orb loopover-orb Bot added the gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier. label Jul 14, 2026
@loopover-orb

loopover-orb Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 LoopOver review result - fixes required

Review updated: 2026-07-14 20:23:21 UTC

2 files · 1 AI reviewer · no blockers · readiness 100/100 · CI failing · blocked

🛑 Suggested Action - Fix Blockers

Review summary
This is a one-entry fix adding the missing "duplicationDelta" to REES_ANALYZER_NAMES so it matches the 57-entry analyzer-metadata.json registry, closing the reachable gap where operators/repo owners couldn't toggle that analyzer via REES_ANALYZERS or .loopover.yml. The insertion point matches the registry's own ordering (right after "duplication"), and the added test compares the full name set against the metadata registry rather than a hardcoded count, which is the right way to prevent future drift. The change is narrow, correct, well-tested, and directly tied to a linked issue.

Nits — 2 non-blocking
  • The failing 'validate-tests (5)' and 'validate' CI checks aren't explained in the PR description — worth confirming they're unrelated to this change before merge.
  • Consider adding a short comment near REES_ANALYZER_NAMES itself (not just the test) noting it must stay a superset-equal set with review-enrichment/analyzer-metadata.json, so future additions to the registry are less likely to be missed at the source.

CI checks failing

  • validate
  • validate-tests (5)
Signal Result Evidence
Code review ✅ No blockers 1 reviewer
Linked issue ✅ Linked #5839
Related work ✅ No active overlap found No same-issue or scoped active PR overlap found.
Change scope ✅ 20/20 Low review scope from cached public metadata (1 linked issue).
Validation posture ✅ 25/25 PR body includes validation/test evidence.
Contributor workload ✅ 10/10 Author activity: 33 registered-repo PR(s), 12 merged, 0 issue(s).
Contributor context ✅ Confirmed Gittensor contributor lourincedaging0-commits; Gittensor profile; 33 PR(s), 0 issue(s).
Gate result ✅ Passing No configured blocker found.
Improvement ✅ Minor risk: clean · value: minor — Code changes are accompanied by test evidence. LLM value judgment: minor — A single missing array entry is a small but concrete fix that unblocks real functionality (toggling duplicationDelta) and is well-anchored to issue #5839.
Linked issue satisfaction

Partially addressed
The core fix (adding "duplicationDelta" to REES_ANALYZER_NAMES) and a drift-guard set-comparison test are delivered, but the two explicitly required deliverable tests—one asserting resolveReesAnalyzers accepts "duplicationDelta" in REES_ANALYZERS, and one asserting resolveEnrichmentAnalyzerSelection can toggle it via .loopover.yml—are not present in the diff.

Review context
  • Author: lourincedaging0-commits
  • Role context: outside_contributor
  • Public audience mode: oss maintainer
  • Lane context: Repository is configured for direct PR review.
  • Public profile languages: not available
  • Official Gittensor activity: 33 PR(s), 0 issue(s).
  • PR-specific overlap: none found.
Contributor next steps
  • Keep the PR focused and include validation evidence before maintainer review.
Signal definitions
  • Related work = same linked issue, overlapping active PRs, or title/path similarity.
  • Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
  • Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
  • Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
  • Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.
[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

  • @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
  • @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
  • A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

🟩 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 LoopOver, a quiet PR intelligence layer for OSS maintainers.

  • Re-run LoopOver review

@loopover-orb

loopover-orb Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Gittensory is closing this pull request on the maintainer's behalf (CI is failing (validate, validate-tests (5))). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.

@loopover-orb loopover-orb Bot closed this Jul 14, 2026
JSONbored added a commit that referenced this pull request Jul 26, 2026
…ed close (#8826)

Both gate_decision writers key the same deterministic row id
(gate:<source>:<project>#<pr>@<sha>) with ON CONFLICT DO UPDATE, so the
last writer wins. One caller records the ACTUAL disposition the bot
acted on; the other derives the verdict from the gate-check conclusion
alone, where success maps to merge.

On a PR the bot closed for a downstream reason (CI failure, policy) the
conclusion-only writer runs last and clobbers the real close with a
merge. On #5861 the close landed at 20:23:31 and the
contradicting merge verdict was written at 20:23:44 -- 13 seconds after
the PR was already closed.

Fleet calibration reads the latest gate_decision as the gate's
prediction, so every such row is scored as a merge prediction that
ended closed: a false positive that never happened. Measured on the
live self-host, 59 rows carry a verdict timestamped after the close
action it contradicts, out of 210 in that class -- biasing published
accuracy DOWNWARD, opposite to the reversal under-counting in #8823.

Advances #8825 (the recording half; scoring policy closes as their own
class is the remaining part).

The DO UPDATE now skips when the incoming write is conclusion-derived
and the stored decision is already 'close'. A close is a terminal
action that already happened and no later conclusion can un-close it.
An explicit action still replaces it, and non-close rows keep
latest-finalize-wins.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix(review): REES_ANALYZER_NAMES is missing duplicationDelta, blocking its env/config toggles

1 participant