Skip to content

test(db): cover pruneExpiredRecords' two defensive ?? 0 arms (#8370)#8451

Closed
philluiz2323 wants to merge 1 commit into
JSONbored:mainfrom
philluiz2323:test-retention-prune-expired-nullish-coverage-8370
Closed

test(db): cover pruneExpiredRecords' two defensive ?? 0 arms (#8370)#8451
philluiz2323 wants to merge 1 commit into
JSONbored:mainfrom
philluiz2323:test-retention-prune-expired-nullish-coverage-8370

Conversation

@philluiz2323

Copy link
Copy Markdown
Contributor

Summary

  • pruneExpiredRecords's two defensive ?? 0 fallback arms (src/db/retention.ts:75 dry-run row?.n ?? 0, and :85 delete-loop result.meta?.changes ?? 0) had zero direct test coverage, unlike the identical pattern on this file's sibling function dedupeSignalSnapshots, which already has dedicated tests for both equivalent arms.
  • Adds two new tests mirroring dedupeSignalSnapshots's existing tests exactly: mock env.DB.prepare to return a row/meta shape missing the relevant field, and assert the function falls back to 0 rather than throwing or producing NaN.
  • Pure test-addition — no production code in src/db/retention.ts was changed, per the issue's explicit scope.

Closes #8370

Scope

  • The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
  • This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
  • This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
  • I linked an issue, or this is small enough that the summary explains why an issue is not needed.

Validation

  • git diff --check
  • npm run actionlint
  • npm run typecheck
  • npm run test:coverage locally; codecov/patch requires ≥99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.
  • npm run test:workers
  • npm run build:mcp
  • npm run test:mcp-pack
  • npm run ui:openapi:check
  • npm run ui:lint
  • npm run ui:typecheck
  • npm run ui:build
  • npm audit --audit-level=moderate
  • New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

  • This PR only touches test/unit/retention.test.ts (test-only, no src/ production-code change) — no UI/MCP/workers/OpenAPI surface is affected. Verified via npx vitest run test/unit/retention.test.ts: all 21 tests pass, including the 2 new ones. Coverage on the target lines (verified directly against coverage/lcov.info): line 75's branch now shows BRDA:75,10,0,25 / BRDA:75,10,1,1 and line 85's shows BRDA:85,11,0,21 / BRDA:85,11,1,1 — both the truthy and nullish-fallback sides of both ?? 0 arms are hit, closing the previously-uncovered branch the issue identified.

Safety

  • No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
  • Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
  • Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. (N/A — no auth/session/CORS changes.)
  • API/OpenAPI/MCP behavior is updated and tested where needed. (N/A — no API/OpenAPI/MCP surface changed.)
  • UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. (N/A — no UI changes.)
  • Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots. (N/A — no visible UI changes.)
  • Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs. (N/A.)

Notes

  • Zero production-code risk: src/db/retention.ts itself is unchanged, exactly as the issue scoped it.

…ed#8370)

Neither the dry-run row?.n ?? 0 fallback (line 75) nor the delete-loop
result.meta?.changes ?? 0 fallback (line 85) had direct test coverage,
unlike the identical pattern on this file's sibling function
dedupeSignalSnapshots, which already has dedicated tests for both. Mirrors
that exact mocking approach: env.DB.prepare returning a row/meta shape
missing the relevant field, asserting the function falls back to 0 rather
than throwing or producing NaN. No production-code changes.
@philluiz2323
philluiz2323 requested a review from JSONbored as a code owner July 24, 2026 13:36
@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 24, 2026
@loopover-orb

loopover-orb Bot commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

Warning

⏸️ LoopOver review result - manual review recommended

Review updated: 2026-07-24 13:59:30 UTC

1 file · 1 AI reviewer · no blockers · CI pending · dirty

⏸️ Suggested Action - Manual Review

Review summary
This PR adds two tests mirroring existing dedupeSignalSnapshots coverage patterns, exercising pruneExpiredRecords' `row?.n ?? 0` (dry-run count) and `result.meta?.changes ?? 0` (delete-loop) fallback arms via mocked D1 responses missing the expected fields. Both mocks are structurally realistic — a D1 `first()` can return `undefined` when no row matches, and `run()` results can genuinely lack `meta` depending on binding shape — so these aren't fabricated-can't-occur scenarios but real defensive branches worth covering. The PR is narrow, test-only, mirrors an established sibling pattern in the same file, and links its closing issue (#8370).

Nits — 4 non-blocking
  • The two new tests are near-duplicates of the existing dedupeSignalSnapshots tests just below them (test/unit/retention.test.ts:151-173 vs :232-254) — consider extracting a small shared mock-env helper to avoid the repeated `as unknown as Env` casting boilerplate.
  • In the delete-loop test (test/unit/retention.test.ts:139-149), relying on `changes = 0 < batchSize` to break the loop after one iteration is implicit — a one-line comment stating that the loop terminates after a single pass would make the assertion's sufficiency clearer to future readers.
  • Consider factoring the repeated `{ DB: { prepare: ... } } as unknown as Env` pattern (now appearing 4 times across dry-run/no-meta tests for both functions) into a small local test helper, e.g. `mockEnvWithFirst(returns)` / `mockEnvWithRun(returns)`, to reduce duplication.
  • The tests only assert on the final `results` array; adding a spy or count check confirming `run`/`first` was called exactly once would make the 'no throw, no NaN' guarantee more explicit rather than inferred from equality on the final shape.

Decision drivers

  • ✅ Code review — No blockers (1 reviewer)
  • ✅ Gate result — Passing (No configured blocker found.)
Context & advisory signals — never blocks the verdict
Signal Result Evidence
Linked issue ✅ Linked #8370
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: 1039 registered-repo PR(s), 613 merged, 126 issue(s).
Contributor context ✅ Confirmed Gittensor contributor philluiz2323; Gittensor profile; 1039 PR(s), 126 issue(s).
Improvement ℹ️ Insufficient signal risk: clean · value: insufficient-signal · LLM: minor
Linked issue satisfaction

Addressed
The PR adds two tests in test/unit/retention.test.ts that directly mock env.DB to omit the row (line 75's row?.n ?? 0) and omit meta (line 85's result.meta?.changes ?? 0), asserting the fallback to 0, mirroring the sibling dedupeSignalSnapshots tests as requested. No production code was changed, matching the issue's explicit scope restriction.

Review context
  • Author: philluiz2323
  • 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: 1039 PR(s), 126 issue(s).
  • PR-specific overlap: none found.
Contributor next steps
  • Start here: Triage stale or unlinked PRs.
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.
🧪 Chat with LoopOver

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

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

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

🟩 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 24, 2026

Copy link
Copy Markdown
Contributor

LoopOver is closing this pull request on the maintainer's behalf (conflicts with the base branch — resolve and open a fresh PR). 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 24, 2026
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.

pruneExpiredRecords's defensive ?? 0 arms have zero test coverage, unlike its sibling function

1 participant