This repository was archived by the owner on Apr 23, 2026. It is now read-only.
fix: Ignore unraisable exceptions during unitcov testing#3326
Merged
mergify[bot] merged 1 commit intoinstructlab:mainfrom Apr 29, 2025
Merged
fix: Ignore unraisable exceptions during unitcov testing#3326mergify[bot] merged 1 commit intoinstructlab:mainfrom
mergify[bot] merged 1 commit intoinstructlab:mainfrom
Conversation
booxter
reviewed
Apr 29, 2025
Newer versions of Docling can raise an exception during custom garbage collection code of TesseractOcrModel that nothing ever catches, because exceptions during garbage collection are generally not caught by anything. The exception is harmless to any of our InstructLab use-cases, and only happens when the TesseractOcrModel was not able to construct itself anyway, which we check for and handle to fallback to EasyOCR or other implementations. However, py3-unitcov by default fails the test suite if any of these unraisable exceptions happen. This adjusts that to not fail the test suite. Messages still get logged about the exception during regular py3-unit testing, so we can see when this gets fixed in Docling, but there's no need for it to actually fail our test suite. Signed-off-by: Ben Browning <[email protected]>
bbrowning
force-pushed
the
docling-gc-exception-ignore
branch
from
0a7c8a5 to
65c1efb
Compare
booxter
approved these changes
Apr 29, 2025
Contributor
booxter
left a comment
booxter
left a comment
There was a problem hiding this comment.
Some TODO comments suggesting that this can removed after bug XXX is fixed in docling would be nice but I won't hold for it. Thanks!!!
nathan-weinberg
approved these changes
Apr 29, 2025
Contributor
|
@mergify backport release-v0.26 |
Contributor
✅ Backports have been createdDetails
|
Contributor
✅ Backports have been createdDetails
|
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 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.
Newer versions of Docling can raise an exception during custom garbage collection code of TesseractOcrModel that nothing ever catches, because exceptions during garbage collection are generally not caught by anything. The exception is harmless to any of our InstructLab use-cases, and only happens when the TesseractOcrModel was not able to construct itself anyway, which we check for and handle to fallback to EasyOCR or other implementations.
However, py3-unitcov by default fails the test suite if any of these unraisable exceptions happen. This adjusts that to not fail the test suite. Messages still get logged about the exception during regular py3-unit testing, so we can see when this gets fixed in Docling, but there's no need for it to actually fail our test suite.
Issue resolved by this Pull Request:
Resolves #3324