Fall back to un-optimized filter chain for unknown filters#1284
Open
Fall back to un-optimized filter chain for unknown filters#1284
Conversation
When AstFilterChain optimization is enabled and a filter chain contains an unknown filter (e.g. local_dt), fall back to the standard nested AstMethod evaluation at parse time instead of failing with an "Unknown filter" error and returning null. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
jasmith-hs
reviewed
Feb 18, 2026
| return null; | ||
| } | ||
| if (filter == null) { | ||
| interpreter.addError( |
Contributor
There was a problem hiding this comment.
This does seem more complicated than it needs to be, and doesn't look to handle disabled filters the same as the non-chained logic.
I think for both instances they will make value null. Could that work instead of building the custom error?
value = null;
continue;…ehavior The non-chained path in JinjavaInterpreterResolver skips disabled filters and passes the value through to the next filter. The chained path was incorrectly returning null for the entire expression, discarding the input and aborting remaining filters. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The previous fix used `continue` alone, but the non-chained path propagates null through subsequent filters rather than skipping. Setting value = null before continuing matches that behavior exactly. Adds parity test confirming optimized and non-chained paths produce identical output for disabled filters in a chain. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Unknown filters are now handled the same as disabled filters in AstFilterChain: set value to null and continue. This matches the non-chained behavior where null propagates through subsequent filters. The parse-time hasUnknownFilter check and buildUnoptimizedFromSpecs fallback are no longer needed and are removed. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fall back to un-optimized filter chain for unknown filters
Summary
Why
The optimized AstFilterChain handles unknown filters differently from the standard EL evaluation path. For example, module | local_dt|unixtimestamp | pprint | md5 would produce no output with the optimization enabled, but works (with a
warning) in the un-optimized path. The optimization should be transparent — falling back when it can't handle a filter ensures parity.