fix(posthog): compare symbol-set release as a nested object, not a string

[JSONbored]

Summary

• PostHog's error_tracking/symbol_sets API returns each symbol set's release as a nested object ({id, hash_id, created_at, metadata, version, project}, per PostHog's own ErrorTrackingRelease/ErrorTrackingSymbolSet dataclasses), never a flat string.
• Both validate-posthog-release.mjs copies (review-enrichment, discovery-index) compared nonBlank(set.release) — which only accepts strings, so it always resolved to undefined for the real object — against our combined release string. The match could never succeed, regardless of retries or timing: this is why "Validate PostHog release" kept failing even after fix(posthog): pass release-name and release-version as separate CLI flags #8624 fixed the release-name/version split.
• Fixed by reconstructing "{project}@{version}" from the real object shape.
• The existing test fixtures (in both twin test suites, plus posthog-upload.test.ts's fake PostHog API server) mocked the wrong flat-string shape, which is exactly why this went undetected — updated them to the real nested shape and added coverage for release: null and a release object missing project/version.

Test plan

• npx vitest run test/unit/discovery-index/validate-posthog-release.test.ts — 16/16 pass
• npm --prefix review-enrichment test — 1379/1379 pass
• Re-cut ORB beta and confirm "Validate PostHog release" passes for real against live PostHog

[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 92.21%. Comparing base (b471ee1) to head (ac4f301).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8629      +/-   ##
==========================================
- Coverage   92.77%   92.21%   -0.57%     
==========================================
  Files         798      798              
  Lines       79464    79464              
  Branches    24078    24078              
==========================================
- Hits        73725    73280     -445     
- Misses       4592     5100     +508     
+ Partials     1147     1084      -63     

Flag	Coverage Δ
backend	92.87% <ø> (-0.79%)	⬇️
rees	89.62% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 3 files with indirect coverage changes

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-25 23:36:41 UTC}

5 files · 1 AI reviewer · 2 blockers · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This fixes a real bug: PostHog's error_tracking/symbol_sets API returns `release` as a nested object ({project, version, ...}), but the old code compared `nonBlank(set.release)` (which only accepts strings) against the combined release string, so the filter could never match. The new `releaseIdentifier()` helper reconstructs `"{project}@​{version}"` from the real object shape and is applied identically in both twin copies of the script. Test fixtures across three suites were updated to the real nested shape and new cases cover `release: null` and objects missing `project`/`version`, which correctly exercise the previously-dead comparison logic.

Nits — 5 non-blocking

• The PR description doesn't link to an open issue (only references PR fix(posthog): pass release-name and release-version as separate CLI flags #8624 as prior context) — per this repo's contributor conventions every external PR should close/link an eligible issue.
• packages/discovery-index/scripts/validate-posthog-release.mjs and review-enrichment/scripts/validate-posthog-release.mjs remain hand-duplicated (pre-existing, not introduced here) — worth a follow-up to extract a shared module so this exact drift (`nonBlank` vs `releaseIdentifier`) can't happen in only one twin again.
• `releaseIdentifier` silently drops any `release` value that's a string (e.g. if PostHog ever reverts or partially migrates the API) rather than logging an unexpected-shape diagnostic, which could make a future regression as silent as this one was.
• Consider adding a runtime assertion/log when `release` is present but neither a string nor object with project/version, so a future API shape change surfaces immediately instead of silently failing to match again (packages/discovery-index/scripts/validate-posthog-release.mjs:34).
• Factor the duplicated `releaseIdentifier`/`nonBlank`/`fetchSymbolSets` logic in the two script twins into a shared module to eliminate the copy-paste risk that caused this exact bug to need fixing twice.

Concerns raised — review before merging

• No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue: This repo's maintainer focus manifest requires every PR to reference a tracked issue. — Link the relevant issue (for example Closes #123) before opening the PR.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue: This repo's maintainer focus manifest requires every PR to reference a tracked issue. — Link the relevant issue (for example `Closes #123`) before opening the PR.

Decision drivers

• ❌ Code review — 2 blockers (1 reviewer)
• ❌ Gate result — Blocking (Repo-configured hard blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
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 (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 13 registered-repo PR(s), 13 merged, 231 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 13 PR(s), 231 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, Ruby, Go, MDX, Shell, Solidity, JavaScript
• Official Gittensor activity: 13 PR(s), 231 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Then work through the remaining 2 steps in the Signals table above.

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 <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> 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