Skip to main content
Common issues and solutions when using QWED Open Responses.

Installation issues

”No module named ‘qwed_open_responses’”

Cause: Package not installed Solution:
For specific integrations:

“ImportError: langchain not found”

Cause: Missing optional dependency Solution:

Guard failures

”No guards configured”

Cause: verify() was called with zero guards. Verification fails closed: verified=False, and blocked=True in strict mode. Earlier versions returned verified=True here. VerifiedOpenAI created without guards also emits a UserWarning at construction for the same reason. Solution: Configure at least one guard.

”verify_structured_output requires a JSON schema or at least one guard”

Cause: verify_structured_output() was called with neither schema nor guards. It raises ValueError because the call would verify nothing. Solution: Pass a schema, at least one guard, or both. An explicit empty schema {} is accepted and matches anything.

”Cannot parse JSON response of type … Expected object”

Cause: verify() received a string that parses to a JSON scalar, array, or null. These are rejected with ValueError because an array or scalar payload would bypass per-item guard inspection. Plain non-JSON strings are still accepted and wrapped as text. Solution: Pass the response as a JSON object (or a string that parses to one). Wrap arrays in an object envelope such as {"output": [...]}.

Verification passed but warnings is non-empty

Cause: A guard returned a warning-severity result. Warnings pass the guard and do not fail verified on their own. They surface in result.warnings as a separate visible state. Solution: This is expected. To escalate warnings to failures, create the verifier with allow_warnings=False.

”SchemaGuard: Missing required field”

Cause: Output doesn’t match expected schema Debug:
Common fixes:
  • Check field names (case-sensitive)
  • Ensure all required fields are present
  • Verify types match schema
SchemaGuard reports only the first validation error, with total_errors set to None and errors_truncated set to True. Fix the reported error and verify again to surface the next one.

”SchemaGuard: Additional properties are not allowed”

Cause: Since v0.6.0, SchemaGuard adds additionalProperties: false to the root object when your schema doesn’t set it. Any undeclared top-level field fails validation. Fix: Declare the field in properties, set additionalProperties explicitly in the schema, or opt out in the constructor:

“JSON response exceeds the character limit”

Cause: verify() received a JSON string longer than 100,000 characters. Related messages are “JSON response exceeds the nesting depth limit” (more than 100 levels) and “JSON response could not be parsed within safe limits” (for example, an oversized integer). These come back as failed verdicts, not exceptions. Fix: Reduce the response size or nesting before verification. For oversized integers specifically, shorten the digit run (split the value or send it as a string) — shrinking unrelated content will not clear an integer failure. SafetyGuard has its own bounds: it fails closed above 12 nesting levels, 10,000 nodes, or 100,000 content characters.

”ToolGuard: Tool in blocklist”

Cause: Agent tried to call a blocked tool Debug:
Options:
  1. Remove tool from blocklist if safe
  2. Use whitelist instead
  3. Create exception for specific cases

”ToolGuard: tool-like content in an unrecognized format”

Cause: The response contains something that looks like a tool call, but it matches none of the recognized envelope shapes. ToolGuard blocks it rather than passing with “No tool calls”. Recognized shapes: type=tool_call, type=function_call, tool_calls[], choices[].message.tool_calls[], content[].type=tool_use. Fix: Emit tool calls in one of the recognized shapes. This block also fires when a call’s JSON-encoded arguments cannot be parsed, exceed 10,000 characters, or nest deeper than 128 levels.

”ToolGuard: malformed tool-call entry”

Cause: A tool_calls, choices, or content collection contains a non-object item, or the response mixes a direct tool call (type=tool_call/function_call) with a sibling collection. Ambiguous envelopes are blocked because validating one side would let the other escape policy checks. Fix: Every entry in a tool-call collection must be an object with a non-blank string tool name, and a response must carry its tool calls in exactly one place.

”MathGuard: No verifiable math found in response”

Cause: The response contains no verifiable math shape. Prose, plain strings, and objects without recognized total, percentage, or inline-calculation fields no longer pass MathGuard vacuously. The guard fails with a warning-severity result, which blocks in strict mode. Options:
  1. Remove MathGuard from stacks that verify non-math responses
  2. Keep the default allow_warnings=True on the verifier so the warning surfaces in result.warnings without failing verification
  3. Add a custom rule so the response shape becomes verifiable

”MathGuard: Calculation mismatch”

Cause: LLM provided wrong calculation Debug:
This is working as intended! The guard caught an LLM hallucination. Options:
  1. Return error to user
  2. Retry with corrected prompt
  3. Use QWED’s math engine directly

”SafetyGuard: PII detected”

Cause: Response contains personally identifiable information Patterns detected:
  • SSN: \d{3}-\d{2}-\d{4}
  • Credit Card: \d{16}
  • Email: Standard email pattern
  • Phone: Various formats
Options:
  1. Block (default): Return error
  2. Redact: Replace with [REDACTED]
  3. Custom patterns: Add your own

”StateGuard: Invalid transition”

Cause: Trying to move to invalid state Debug:
Fix: Review your state machine definition.

Integration issues

LangChain callback not triggering

Check callback is added:
Check tool is being called:

OpenAI wrapper not verifying

Check you’re using VerifiedOpenAI:
Check tool_choice is set:

Express middleware returns 422 “Request verification failed”

Cause: In the npm package, verifyRequestBody returns HTTP 422 with code QWED_REQUEST_BLOCKED when a request declares a body but Express has no parsed body. A request declares a body with a non-zero Content-Length or a Transfer-Encoding header. This happens even when blockOnFailure is false, because the middleware can’t verify a body it can’t see. Requests without a body continue to the next handler. Requests whose body parses to an empty JSON object also continue. Fix: Register a body parser before the QWED middleware:
Also confirm the request’s Content-Type matches the parser you registered. A body that express.json() skips stays unparsed and is blocked.

Guards not being applied

Check guard order:
Check guard is configured:

Performance issues

Verification is slow

Reduce guards:
Cache schemas:

Too many false positives

Tune PII patterns:
Adjust tolerance:

Common errors reference


Getting help

  1. GitHub Issues: github.com/QWED-AI/qwed-open-responses/issues
  2. Documentation: docs.qwedai.tech/open-responses
  3. Examples: GitHub Examples