feat(compat): salvage JSON-string submit payloads before failing schema validation (#185)#201
Conversation
…ma validation (#185) Weak models frequently call the terminal submit tool with a JSON STRING (often markdown-fenced) instead of the object the schema wants. Live evidence (qwen/qwen3-coder:free): planner + worker + verify gate passed, two commits landed — then PR composition failed schema validation 3x ('expected object, received string') and the group blocked at pr-open, one step from success. submittedOutput now, on a failed validation of a STRING payload, strips a single ```-fence and JSON.parses it, then re-validates: success is accepted as if the object had been submitted directly. This runs upstream of the #101 retry kernel, so retries only spend on genuinely wrong shapes. A non-string, non-parsing, or still-invalid value keeps the existing typed `invalid` result (with the parsed value's issues when it parsed but didn't validate). Zero cost to well-behaved models; provider-agnostic (no model sniffing). Tests: stringified-valid + fenced-valid salvage to ok; stringified-but-schema- invalid stays invalid with the parsed-object issues; non-JSON string and object paths unchanged. Part of #196.
|
@coderabbitai full review |
✅ Action performedFull review finished. You're currently rate limited under our Fair Usage Limits Policy. Your recent PR review activity is in the 95th percentile or higher among CodeRabbit users, so adaptive limits apply. Your next review will be available in 46 minutes. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough
ChangesJSON submit payload salvage
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant SubmitToolCall
participant submittedOutput
participant salvageJsonString
participant outputSchema
SubmitToolCall->>submittedOutput: Provide call.input
submittedOutput->>outputSchema: Validate original input
outputSchema-->>submittedOutput: Return validation failure
submittedOutput->>salvageJsonString: Parse string or fenced JSON
salvageJsonString-->>submittedOutput: Return parsed value
submittedOutput->>outputSchema: Validate parsed value
outputSchema-->>submittedOutput: Return typed result or parsed issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai full review |
✅ Action performedFull review finished. |
Closes #185. XS P1 batch from the parity verification (#196).
Problem
Weak models frequently call the terminal
submittool with a JSON string (often markdown-fenced) instead of the object the schema wants. Live evidence (qwen/qwen3-coder:free): planner + worker + verify gate passed, two commits landed — then PR composition failed schema validation 3× (expected object, received string) and the group blocked atpr-open, one step from success.Fix
submittedOutput, on a failed validation of a string payload, strips a single ```-fence andJSON.parses it, then re-validates: success is accepted as if the object had been submitted directly. Runs upstream of the #101 retry kernel, so retries only spend on genuinely wrong shapes. A non-string, non-parsing, or still-invalid value keeps the existing typed `invalid` result (with the parsed value's issues when it parsed but didn't validate). Zero cost to well-behaved models; provider-agnostic (no model sniffing).Tests
ok; stringified-but-schema-invalid staysinvalidwith the parsed-object issues; non-JSON string and object paths unchanged.test:node(compat 258) + biome.Part of #196.
Summary by CodeRabbit