Skip to content

fix(engine): apply the JSON→YAML fallback in config-lint's canonical parser too - #7287

Merged
loopover-orb[bot] merged 1 commit into
JSONbored:mainfrom
bitfathers94:fix/issue-7244
Jul 19, 2026
Merged

fix(engine): apply the JSON→YAML fallback in config-lint's canonical parser too#7287
loopover-orb[bot] merged 1 commit into
JSONbored:mainfrom
bitfathers94:fix/issue-7244

Conversation

@bitfathers94

Copy link
Copy Markdown
Contributor

Summary

  • config-lint had two independent top-level-object parsers for the same manifest text that disagreed on JSON/YAML fallback. parseTopLevelObject (feeding unknownTopLevelWarnings) retried with parseYaml when JSON.parse threw on a {/[-prefixed text — valid YAML flow mappings can start that way — but parseCanonicalTopLevelObject (feeding recognizedFieldsFor) did not, so buildConfigLintReport silently reported zero recognized fields for a valid YAML-flow-mapping manifest that unknownTopLevelWarnings parsed and warned about, producing internally inconsistent results for the identical input.
  • De-duplicated both into one shared parseManifestTopLevelObject used by both callers, so the two can never drift on whether a manifest text parses. Added a regression test asserting a valid YAML flow mapping starting with { now yields non-empty recognized fields consistent with the unknown-field warning for the same text.

Scope

  • The PR title follows type(scope): short summary Conventional Commit format.
  • 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 a currently open issue this PR resolves — Closes #7244.

Validation

  • npm run typecheck
  • npm run build --workspace @loopover/engine
  • npm run test --workspace @loopover/engine (589 passing)
  • npm run test:engine-parity
  • test/unit/selfhost-config-lint.test.ts — 100% line and branch coverage on packages/loopover-engine/src/config-lint.ts (43/43 branches)
  • New branch (JSON→YAML fallback in the shared parser) covered by the #7244 regression test plus the existing flow-mapping test
  • Non-applicable checks (UI/MCP/OpenAPI) skipped: this is a backend-engine-only change to config-lint.ts and its unit test; no UI, API surface, MCP, docs, or dependency changes.

Safety

  • No secrets, wallet details, hotkeys, coldkeys, PATs, trust scores, or private maintainer evidence are exposed. The change actually improves value redaction indirectly by keeping parser warnings name-only; the regression test asserts supplied values (hidden, secret) never leak into the result.
  • No auth/cookie/CORS/GitHub App/Cloudflare/session surface touched.
  • No UI changes — no UI Evidence required.

Notes

  • The existing "checks unknown fields in YAML flow mappings that start like JSON" test previously asserted the buggy recognizedFields: []; it is updated to the now-correct ["wantedPaths"], matching what unknownTopLevelWarnings already reported for the same text.

Closes #7244

…parser too

config-lint had two independent top-level-object parsers for the same manifest
text that disagreed on JSON/YAML fallback. `parseTopLevelObject` (used by
`unknownTopLevelWarnings`) retried with `parseYaml` when `JSON.parse` threw on a
`{`/`[`-prefixed text — YAML flow mappings can start that way while still being
valid manifest syntax. `parseCanonicalTopLevelObject` (used by
`recognizedFieldsFor`) did not: it caught the `JSON.parse` failure and returned
null → [], so `buildConfigLintReport` silently reported zero recognized fields
for a valid YAML-flow-mapping manifest that `unknownTopLevelWarnings` happily
parsed and warned about — the two functions produced inconsistent results for
the same input in the same report call.

De-duplicate the two into one shared `parseManifestTopLevelObject` used by both
callers, so recognizedFieldsFor and unknownTopLevelWarnings can never drift on
whether a given manifest text parses. Add a regression test asserting a valid
YAML flow mapping starting with `{` now yields non-empty recognized fields
consistent with the unknown-field warning for the same text.

Closes JSONbored#7244
@bitfathers94
bitfathers94 requested a review from JSONbored as a code owner July 19, 2026 12:39
@superagent-security

Copy link
Copy Markdown
Contributor

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

@codecov

codecov Bot commented Jul 19, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.81%. Comparing base (2372739) to head (11fa6ec).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #7287      +/-   ##
==========================================
- Coverage   93.81%   93.81%   -0.01%     
==========================================
  Files         704      704              
  Lines       69462    69454       -8     
  Branches    18896    18892       -4     
==========================================
- Hits        65167    65159       -8     
  Misses       3302     3302              
  Partials      993      993              
Flag Coverage Δ
shard-1 43.62% <0.00%> (+<0.01%) ⬆️
shard-2 37.34% <0.00%> (+<0.01%) ⬆️
shard-3 33.18% <100.00%> (+0.12%) ⬆️
shard-4 33.74% <0.00%> (-0.57%) ⬇️
shard-5 32.88% <100.00%> (+0.69%) ⬆️
shard-6 45.50% <50.00%> (-0.29%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
packages/loopover-engine/src/config-lint.ts 100.00% <100.00%> (ø)

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

loopover-orb Bot commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

Tip

✅ LoopOver review result - approve/merge recommended

Review updated: 2026-07-19 12:52:23 UTC

2 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

  • safe to merge

Review summary
This PR unifies two divergent top-level-object parsers in config-lint.ts into a single `parseManifestTopLevelObject` shared by both `recognizedFieldsFor` and `unknownTopLevelWarnings`, fixing a real inconsistency where a valid YAML flow mapping starting with `{` (invalid strict JSON) was recognized by `unknownTopLevelWarnings` but silently produced zero recognized fields via the old `parseCanonicalTopLevelObject`. The fix is at the correct layer (the shared parser), the diff is small and self-contained, and the new/updated tests directly exercise the real code path (a `{`-prefixed YAML flow mapping with unquoted keys) rather than fabricating an unreachable scenario. The existing test at line ~271-281 was correctly updated to reflect the new (correct) behavior instead of being left asserting the old bug.

Nits — 4 non-blocking
  • config-lint.ts:99-111 — the retained `looksLikeJson` check inside `parseManifestTopLevelObject` duplicates logic that could arguably be simplified now that there's only one call site chain, though this is a stylistic point given the function is already well-commented.
  • The PR description claims 43/43 branch coverage but this can't be independently verified from the diff alone — worth double-checking in CI coverage output if not already gated by codecov/patch (which passed).
  • Consider adding a case-sensitivity or whitespace-only edge-case test (e.g. `" {} "`) if not already covered elsewhere, though existing oversize/blank tests likely cover the trim path.
  • The doc comment on `parseManifestTopLevelObject` (config-lint.ts:96-99) is a good addition explaining the YAML-flow-mapping rationale — nice to see the 'why' captured for future readers.

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 #7244
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: 38 registered-repo PR(s), 25 merged, 0 issue(s).
Contributor context ✅ Confirmed Gittensor contributor bitfathers94; Gittensor profile; 38 PR(s), 0 issue(s).
Improvement ✅ Minor risk: clean · value: minor · LLM: moderate
Linked issue satisfaction

Addressed
The diff replaces the two divergent parsers with a single shared parseManifestTopLevelObject helper that applies the JSON→YAML fallback consistently, used by both recognizedFieldsFor and unknownTopLevelWarnings, and adds a regression test showing a YAML flow-mapping manifest starting with '{' now yields consistent non-empty recognized fields.

Review context
  • Author: bitfathers94
  • 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: 38 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.
🧪 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 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LoopOver approves — the gate is satisfied and CI is green.

@loopover-orb
loopover-orb Bot merged commit d54bc35 into JSONbored:main Jul 19, 2026
17 checks passed
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.

config-lint's recognizedFieldsFor lacks the YAML-fallback-on-JSON-failure its sibling unknownTopLevelWarnings has

1 participant