Repository navigation
cluster-only labels fails: Expecting value: line 1 column 6 (char 5) #1690
Description
Bug Description
graphify cluster-only <path> fails to label communities and falls back to Community N placeholders with a JSON decode error.
Steps to Reproduce
- Install graphify on Windows/Hermes:
pip install graphifyy && graphify install --platform hermes - Use a corpus with mixed code + 1 doc file and set a working LLM key, e.g.:
export GOOGLE_API_KEY=...graphify "H:/path/to/small-project"
- Run:
graphify cluster-only "H:/path/to/small-project"
Expected Behavior
All communities are labeled with meaningful names and the report is generated.
Actual Behavior
[graphify label] batch 1/1 (6 communities) failed: Expecting value: line 1 column 6 (char 5)
[graphify label] warning: community labeling failed (Expecting value: line 1 column 6 (char 5)); using Community N placeholders.
GRAPH_REPORT.md is still written, but all community names remain Community N.
Environment
- OS: Windows 10
- Shell: Git Bash / MSYS2
- graphify:
0.9.6 - Hermes: installed via
graphify install --platform hermes - LLM backend: gemini via
GOOGLE_API_KEY/--backend
Notes
- Initial extraction succeeds, including semantic extraction via gemini.
- Re-running
cluster-onlyon the existing graph still reproduces the JSON parse failure. - Related: issue bug:
graphify install --platform hermesinstalls skill to wrong directory on Windows #1403 was fixed for Windows install path; this appears unrelated.
Activity
Fix: salvage truncated labeling replies and account for labeling toke…
safishamsi commentedon Jul 6, 2026
Fixed on
v8(21b851b), shipping in the next release.Expecting value: line 1 column 6 (char 5)is a reply that failed a strictjson.loads(typically truncated mid-object, or a model preamble before the JSON). Two changes:_parse_label_responsenow salvages the complete"id": "name"pairs from a reply that failsjson.loads, raising only when no pairs can be recovered. So a partial reply now yields the names that did arrive instead of failing the whole batch (the missing cids fall back toCommunity N).256 + 48*n, was64 + 24*n) to give models that prepend a short preamble enough headroom to finish the JSON.Honest caveat: I could not reproduce the exact provider-side truncation without a live key, so this fixes the parsing/budget mechanism rather than a confirmed byte-for-byte repro. If it still recurs, the salvage path now logs the offending batch to stderr. Thanks for the report.
Release 0.9.8
Fix: salvage truncated labeling replies and account for labeling toke…
Release 0.9.8