-
Notifications
You must be signed in to change notification settings - Fork 1
Pipeline Plan 242
File: scripts/sw-loop.sh:561-608 — _extract_text_from_json() function
The execution path when Claude outputs a JSON object ({...}) instead of an array ([...]):
-
Line 579 — Case 2 checks
first_char == "["→ false (it's{). The entire jq extraction block is skipped, even though jq is available. -
Line 599 — Case 3 catches
first_char == "{"and unconditionally prints"JSON output but jq not available". This is misleading because jq was never tried — the condition above only checked for arrays.
-
Most likely (confirmed): Case 2 only handles JSON arrays (
[). When Claude's--output-format jsonoutputs an object ({...}), the code falls through to Case 3 which prints a misleading "jq not available" warning regardless of whether jq is installed. -
Less likely: Claude always outputs arrays and the
{case never fires. Disproved — the issue reporter observed this in practice. - Unlikely: jq is actually unavailable. Disproved — the warning text itself is the problem, not jq availability.
-
Pros: Actually parses the JSON object and extracts
.result, providing the correct text output. Fixes both the misleading warning AND extracts useful content. - Cons: Slightly more code, but the logic is straightforward.
-
Blast radius: Minimal — only changes the
_extract_text_from_jsonfunction. The fallback behavior (Case 3) still exists for the rare case where jq is truly unavailable. -
Complexity: Low — adds one
elifbranch with a parallel jq extraction for objects.
- Pros: Smallest possible change (1-2 lines).
-
Cons: Doesn't actually parse the JSON object — still uses raw output even when jq could extract
.result. Fixes the symptom but not the underlying limitation. - Blast radius: Trivial.
Option A is the right fix because it's still a small change (10-15 lines) and it actually solves the problem properly — extracting .result from JSON objects the same way we extract from arrays. The warning fix in Case 3 comes along as part of the change.
| Risk | Impact | Mitigation |
|---|---|---|
| New jq extraction path breaks on unexpected JSON shapes | Low — 2>/dev/null and ` |
|
| Change affects JSON array handling | None — array path (Case 2) is unchanged | Only adding a new elif for objects |
| Test suite expectations break | Low — existing tests only cover arrays and plain text | Add new test for JSON object input |
| Bash 3.2 incompatibility | None — using only if/elif, [[, and pipes |
No new syntax |
-
scripts/sw-loop.sh— Fix_extract_text_from_json()to handle JSON objects -
scripts/sw-loop-test.sh— Add test case for JSON object extraction
Restructure Cases 2 and 3 to:
- Case 2a: JSON array (
[) with jq → extract.[-1].result(unchanged) - Case 2b: JSON object (
{) with jq → extract.resultdirectly - Case 3: JSON but no jq → accurate warning message
# Case 2: Valid JSON — extract .result with jq if [[ "$first_char" == "[" ]] && command -v jq >/dev/null 2>&1; then # ... existing array extraction (unchanged) ... elif [[ "$first_char" == "{" ]] && command -v jq >/dev/null 2>&1; then local extracted extracted=$(jq -r '.result // empty' "$json_file" 2>/dev/null) || true if [[ -n "$extracted" ]]; then echo "$extracted" > "$log_file" return 0 fi # Try .content fallback for objects too extracted=$(jq -r '.content // empty' "$json_file" 2>/dev/null) || true if [[ -n "$extracted" ]]; then echo "$extracted" > "$log_file" return 0 fi warn "JSON object output has no .result field — check $json_file" echo "(no text result in JSON output)" > "$log_file" return 0 fi # Case 3: Looks like JSON but no jq — can't parse, use raw if [[ "$first_char" == "[" || "$first_char" == "{" ]]; then warn "JSON output but jq not available — using raw output" cp "$json_file" "$log_file" return 0 fi
Key: Case 3's warning is now accurate — it only fires when jq is genuinely unavailable (both Case 2 branches check command -v jq first).
Add a new test in the "json extraction robustness" section (after Test 19, around line 299) that tests JSON object input:
# Test: JSON object → extracts .result echo '{"type":"result","subtype":"success","result":"Object extraction works"}' > '$tmpdir/obj.json' _extract_text_from_json '$tmpdir/obj.json' '$tmpdir/out_obj.log' ''
Then assert grep -q "Object extraction works" "$tmpdir/out_obj.log".
./scripts/sw-loop-test.sh
- Task 1: Read and understand the current
_extract_text_from_jsonfunction (lines 561-608) - Task 2: Add
elifbranch for JSON objects ({) with jq extraction insw-loop.sh - Task 3: Verify Case 3 warning now only fires when jq is genuinely unavailable
- Task 4: Add test case for JSON object extraction in
sw-loop-test.sh - Task 5: Run
sw-loop-test.shand verify all tests pass - Task 6: Manually verify the fix handles edge cases (empty
.result, missing.result)
Task dependencies: Task 1 → Task 2 → Task 3 (sequential). Task 4 depends on Task 2. Task 5 depends on Tasks 2-4. Task 6 depends on Task 5.
-
Existing tests — Run
sw-loop-test.shto ensure no regressions in array extraction, empty file handling, plain text pass-through, nested JSON, and binary input. -
New test — JSON object with
.resultfield → verify extraction works. -
Edge cases covered by existing fallbacks:
- JSON object without
.result→ warning + placeholder (same behavior as array without.result) - No jq available → accurate "jq not available" warning + raw output
- Non-JSON input → pass-through (unchanged Case 4)
- JSON object without
-
_extract_text_from_jsoncorrectly extracts.resultfrom JSON objects ({...}) -
_extract_text_from_jsonstill correctly extracts.resultfrom JSON arrays ([...]) - The misleading "jq not available" warning no longer fires when jq IS available
- The "jq not available" warning still fires when jq is genuinely not installed
- New test case for JSON object extraction passes
- All existing
sw-loop-test.shtests pass - No Bash 3.2 incompatibilities introduced
- Run
./scripts/sw-loop-test.sh— all tests pass including the new JSON object test - Confirm the warning text change: grep for the old misleading message to ensure it's gone from the jq-available path
- Confirm Case 3 only fires when
command -v jqfails (structural code review)
Not applicable — this is a bash function fix, not an API change.
Not applicable — no API endpoints.
Not applicable.
Not applicable — internal function change, no public API.