[CRITICAL] Auto-fixing Output Parser Lacks Retry Limits - Potential for Infinite Cost Escalation

Feature Requests
1

Hi n8n community,
I’m raising a critical concern about the Auto-fixing Output Parser node that could lead to significant cost overruns in production environments.

The Problem

The Auto-fixing Output Parser node documentation states it “calls out to another LLM to fix any errors” but provides no mention of retry limits. This creates a scenario where the node could theoretically loop indefinitely if the LLM consistently fails to produce valid output.

Real-World Risk

This isn’t theoretical. I’ve seen production incidents where similar retry mechanisms without limits resulted in:

  • Thousands of dollars in unexpected LLM API costs over weekends
  • Multiple workflow re-executions after timeouts, each triggering new auto-fix cycles
  • Cumulative cost escalation even with n8n’s execution timeouts in place

Current Documentation Gap

  1. The Auto-fixing Output Parser docs don’t specify ANY retry limits
  2. “Retry on Fail” at the node level appears to be independent of the auto-fixing mechanism
  3. My personnalité expérience shows the auto-fixing can fail repeatedly even with “Retry on Fail” enabled
  4. No clear guidance on cost protection for production deployments

Evidence from Community

Multiple users report persistent failures even with both auto-fixing and retry mechanisms enabled:

  • “model output doesn’t fit required format” errors persist despite retries
  • Code blocks in LLM output systematically break the parser
  • Failed executions continue until max node retries, not auto-fixing limits

Proposed Solution

Add a Max Auto-fix Attempts parameter to the Auto-fixing Output Parser node configuration:

┌─────────────────────────────────────┐
│ Auto-fixing Output Parser Settings  │
├─────────────────────────────────────┤
│ ☑ Enable Auto-fixing               │
│ Max Auto-fix Attempts: [3] ▼       │
│ Auto-fix Timeout (ms): [30000]     │
└─────────────────────────────────────┘

This would:

  • Prevent infinite retry loops within each execution
  • Provide predictable cost control per workflow run
  • Allow graceful fallback to error handling
  • Align with industry best practices (exponential backoff, circuit breakers)

Workaround (Until Fixed)

For now, I’m implementing external circuit breakers and considering switching to basic LLM Chain + Structured Output Parser as several community members suggest.

Request to n8n Team

Can we get:

  1. Official confirmation of current auto-fixing retry behavior
  2. Roadmap for adding retry limits to this node
  3. Updated documentation with cost protection guidelines
    This affects production reliability and cost predictability - two critical factors for enterprise adoption.
    Has anyone else encountered similar cost escalation issues with auto-fixing mechanisms?
    Tags: #auto-fixing #output-parser #cost-control #production #api-limits