fix(query_analyzer): handle dateparser internal crashes gracefully - #893
Merged
Conversation
DateparserQueryAnalyzer.analyze() called dateparser.search.search_dates()
without any error handling, so internal bugs in the third-party library
propagated all the way up the search/consolidation pipeline and failed
the calling task.
Observed traceback:
File ".../engine/query_analyzer.py", line 140, in analyze
results = self._search_dates(query, settings=settings)
File ".../dateparser/search/search.py", line 294, in search_dates
"Dates": self.search.search_parse(...)
File ".../dateparser/search/search.py", line 168, in search_parse
translated, original = self.search(shortname, text, settings)
File ".../dateparser/languages/locale.py", line 224, in translate_search
[original_tokens[i], original_tokens[i + 1]],
IndexError: list index out of range
Wrap the call in a try/except so any parser failure is treated as
"no temporal constraint found" — the caller can then fall back to
non-temporal retrieval instead of erroring out the whole task. The
failure is logged at WARNING level so we still notice it.
Add a regression test that monkey-patches _search_dates to raise an
IndexError and asserts the analyzer returns an empty constraint and
emits a warning log.
This was referenced Aug 6, 2026
Closed
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.
Summary
DateparserQueryAnalyzer.analyze()callsdateparser.search.search_dates()without any error handling. The third-party library has been observed to crash with internal errors on certain query inputs, propagating the exception all the way up the search/consolidation pipeline and failing the calling task.Observed traceback
This has been observed repeatedly on the same bank, suggesting at least one stored memory contains text that reliably triggers the dateparser bug. Each consolidation cycle re-runs the same query and crashes the same way.
Fix
Wrap the
_search_datescall in atry/exceptso any parser failure is treated as "no temporal constraint found" — the caller falls back to non-temporal retrieval instead of erroring out the whole task. The failure is logged at WARNING level so it's still visible.Test plan
_search_datesto raise anIndexError, asserts the analyzer returns an empty constraint, and asserts a warning is logged.test_query_analyzer.pysuite — 16 passed.