docs: add robust parsing with automatic retry to structured outputs guide

[codeananda]

Summary

Adds documentation for handling parsing errors in production when using structured outputs. This addresses a common issue where LLMs return malformed outputs that cause parsing failures.

Changes

• Added new "Handling parsing errors" section to the structured outputs concept page
• Shows how to use OutputFixingParser for automatic retry on malformed outputs
• Clarifies that with_structured_output() doesn't provide built-in retry functionality
• Links to existing RetryOutputParser guide for advanced cases requiring prompt context

Motivation

In production environments, LLM outputs frequently fail to parse correctly due to network issues, incomplete responses, or model errors. This documentation helps users build more robust systems by showing them a simple pattern for automatic retry.

Related to #32977 - addresses the need for better error handling documentation in structured outputs.

Testing

Documentation-only change, no code modifications required.

Additional Context

This pattern has been invaluable in my own production systems. The current documentation doesn't make it clear that with_structured_output() lacks retry functionality, and users need to know about OutputFixingParser as a solution.

Future enhancement suggestion: Consider adding a retry_on_parsing_error parameter to with_structured_output() to make this functionality built-in.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
langchain	Ready	Preview	Comment	Sep 26, 2025 7:16pm

[eyurtsev]

FYI we're not including this in langchain_v1 yet. We'll likely need to figure out how to have the same functionality exposed in v1.

[codeananda]

@eyurtsev what is the recommended approach in V1? with_structured_output?

[eyurtsev]

@codeananda for your use cases, curious do any of these apply:

1. using small / less powerful model (due to latency)
2. work in a language other than English / Spanish (i.e., languages with tons of data)
3. using schema that has difficult constraint (e.g., an integer between 5-10)

Basically if you know in which situations things are more likely to fail -- it'd be helpful for the maintainers :)

[codeananda]

@eyurtsev

None of the things you suggested apply.

• Currently using big models (Sonnet 4 and Llama Maverick 4) as they give better quality
• Working only in English (but working with a large variety of documents, many scanned pdfs of varying quality)
• Schemas aren't too complicated at the minute either. We're actually asking for json, say, 8 json dicts as output each with the same 4 keys in the same order. I found that every now and then Sonnet does something a bit random which causes it to break. I imagine the same thing will happen here with Pydantic, hence the PR.

Is that helpful?

[mdrxy]

Closing this as current docs are frozen - new docs PRs should be opened against https://github.com/langchain-ai/docs

Thank you! 🙏