fix(signals): avoid request-time burden forecast scans

[JSONbored]

Motivation

• Prevent unauthenticated or low-privileged callers from repeatedly triggering expensive request-time scans and CPU work by removing synchronous computation on burden-forecast cache misses.
• Ensure request-path helpers only return persisted snapshots or a clear not-found response to avoid unbounded per-request DB load.

Description

• Changed loadOrComputeBurdenForecastResponse to only return persisted snapshot envelopes and return null on cache miss instead of computing a forecast from issue/PR listers; this removes the request-time calls to broad listers. (src/services/burden-forecast.ts)
• Updated the MCP tool gittensory_get_burden_forecast description and summary to reflect cached-only behavior and to return a not_found payload when no snapshot exists. (src/mcp/server.ts)
• Adjusted unit and integration tests to assert that known but uncached repos do not produce computed burden-forecast payloads and that broad request-time listers are not invoked. (test/unit/burden-forecast.test.ts, test/integration/api.test.ts)

Testing

• Ran the focused test suites with npm run test -- test/unit/burden-forecast.test.ts test/integration/api.test.ts, and all tests passed.
• Ran type-checking with npm run typecheck, which succeeded with no errors.
• Performed a whitespace/format check with git diff --check, which reported no issues.

---

Codex Task

[ghost]

Note

Gittensory Gate skipped

PR closed before full evaluation. No late first comment was created.

Signal	Result	Evidence	Action
Gate result	⚠️ Skipped	#906 is no longer open.	No action.

---

💰 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.

[superagent-security]

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.71%. Comparing base (5d9d73a) to head (6ff6070).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #906      +/-   ##
==========================================
- Coverage   96.71%   96.71%   -0.01%     
==========================================
  Files         108      108              
  Lines       14641    14637       -4     
  Branches     5298     5297       -1     
==========================================
- Hits        14160    14156       -4     
  Misses        102      102              
  Partials      379      379              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ghost]

gittensory · advisory review

Reviewed 4 changed file(s) — two independent AI reviewers.

Changed files: src/mcp/server.ts, src/services/burden-forecast.ts, test/integration/api.test.ts, test/unit/burden-forecast.test.ts

Suggested action: 🛠️ Request changes. (reviewers split: merge / request changes) Address the suggestions below before merging.

Reviewer A · gpt-oss-120b — recommends ✅ merge
This PR removes on‑demand burden‑forecast computation, returning null when no cached snapshot exists, and updates descriptions, summaries, and tests accordingly. The change aligns with the intent to avoid request‑time heavy scans and the test suite has been adjusted to reflect the new behavior.

Suggestions

• Add or update API documentation to note that the burden forecast is only returned when a cached snapshot is available.
• Ensure TypeScript typings for loadOrComputeBurdenForecastResponse explicitly allow null to avoid compile‑time errors.
• Add a unit/integration test confirming that a cached forecast is still returned correctly for a repo with a snapshot.

Worth double-checking

• Consumers (UI or other services) that assume burdenForecast fields are always present may need to handle their absence gracefully.
• If the function signature wasn’t updated to allow null, the code may fail type‑checking in strict mode.

Reviewer B · mistral-small-3.1-24b-instruct — recommends 🛠️ request changes
The PR removes the computation of the burden forecast at request time, instead returning null. It updates the API description and tests accordingly. The change is focused and well-documented in the tests.

Suggestions

• Consider adding a comment explaining why the computation is removed and what the implications are.
• Ensure that all callers of loadOrComputeBurdenForecastResponse handle the null return value gracefully.

Worth double-checking

• Verify that all parts of the system that rely on the burden forecast handle the null return value correctly.
• Check for any edge cases where the absence of a burden forecast might cause issues.