While reviewing _Extract.invoke, I noticed that patch application failures do not propagate to the retry loop. Specifically, when _apply_patch(target, patches) throws, the exception is logged but not re-raised:
trustcall/_base.py (around lines 806–825)
This creates a state where the extractor silently loses the ability to converge, because the retry mechanism defined here:
trustcall/_base.py (around lines 1005–1014)
is never triggered.
The result is not just a missed retry — it creates an epistemic boundary violation:
The system cannot distinguish between:
• a successfully resolved schema update, and
• a failed patch application that was absorbed silently.
This breaks the extractor’s ability to self-correct through iterative patch refinement, which is the core reliability mechanism trustcall introduces.
From a control-flow perspective, patch application is part of the convergence loop, not a terminal side-effect. Failure to apply a patch must propagate as a retry-eligible state transition, otherwise the extractor enters a false convergence condition.
Concretely, this could be resolved by re-raising the exception after logging, or explicitly returning a retry-triggering structure consistent with the existing validation retry path.
Question:
Is the current behavior intentional to allow partial convergence, or is this an unintended break in the retry boundary?
If unintended, I can draft a PR that preserves retry propagation while maintaining backwards compatibility.
While reviewing _Extract.invoke, I noticed that patch application failures do not propagate to the retry loop. Specifically, when _apply_patch(target, patches) throws, the exception is logged but not re-raised:
trustcall/_base.py (around lines 806–825)
This creates a state where the extractor silently loses the ability to converge, because the retry mechanism defined here:
trustcall/_base.py (around lines 1005–1014)
is never triggered.
The result is not just a missed retry — it creates an epistemic boundary violation:
The system cannot distinguish between:
• a successfully resolved schema update, and
• a failed patch application that was absorbed silently.
This breaks the extractor’s ability to self-correct through iterative patch refinement, which is the core reliability mechanism trustcall introduces.
From a control-flow perspective, patch application is part of the convergence loop, not a terminal side-effect. Failure to apply a patch must propagate as a retry-eligible state transition, otherwise the extractor enters a false convergence condition.
Concretely, this could be resolved by re-raising the exception after logging, or explicitly returning a retry-triggering structure consistent with the existing validation retry path.
Question:
Is the current behavior intentional to allow partial convergence, or is this an unintended break in the retry boundary?
If unintended, I can draft a PR that preserves retry propagation while maintaining backwards compatibility.