Repository navigation
fix(foundation): close the engine too when the Extractor constructor raises after choosing one (#2107) - #2119
Merged
Conversation
Owner
Author
|
GOOD TO GO at
|
Contributor
|
Coverage: 91.55% (unit tier, Python 3.15,
Per-file detail: the |
Owner
Author
|
Ready to merge at
This closes #2107. |
Owner
Author
|
In this case, I would rather prefer to revise the Extractor's built-in |
Owner
Author
|
Understood: the constructor should reuse the Extractor's own cleanup path rather than carry a second, hand-rolled one. Today that path is split in two:
The plan:
I'm dispatching the revision on this branch now. It will come back with a fresh review. |
…raises after choosing one (#2107) - Extractor: the constructor's error handler now calls _cleanup(failed=True) instead of closing the input by hand, so the chosen engine is closed too. With failed set, the flow tracer is not finished and _flag_e is not set, a missing engine (unknown format) is skipped, and an Exception from the engine's close is logged so the original error still propagates. - Extractor: _cleanup and __exit__ now share one close path, _release. __exit__ behaves as before: no trace finish, and close errors propagate. - PyShark: close() is a no-op before run() opened the capture. - Tests: extend the #2107 unit tests to cover a failed constructor not finishing the trace, the no-engine path, and __exit__ closing through _release; select the fake engine the way _select_engine does since #2113. Tests: #2107 file 8 passed; related extraction tests 127 passed; foundation plain-unittest leg 730 tests, 0 failures, 0 errors.
JarryShaw
force-pushed
the
fix/2107-close-engine-on-constructor-error
branch
from
October 24, 2026 00:39
3ec2947 to
972f5bc
Compare
Owner
Author
|
GOOD TO GO at
|
Owner
Author
|
Ready to merge at
This closes #2107. |
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
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.
make pylint,make mypy,make isort)make testpasses, and a test case covers the changeWhat is the purpose of your pull request?
fix— bug fixesDescription of your pull request and other information
Closes #2107. Before this, when an engine raised out of the
Extractorconstructor after_exengwas set, #2106's handler closed the input but never the engine. PyShark's_extmpcapture, its temp file and itstsharkstayed open until GC.Fix: after closing the owned input, the handler takes
self.__dict__.get('_exeng')and, if one exists, callsclose()insidetry: … except Exception:(logged at debug), then does a bareraise. The input is closed first and the engine second, the same order as_cleanupand__exit__. A failing close cannot replace the original exception, andExceptionrather thanBaseExceptionlets a Ctrl-C during close through.PyShark: its
close()raisedAttributeErrorbeforerun(), when_extmpis stillNone. It now skips that case. Every built-in engine'sclose()is now safe on a half-started engine and when called twice; theKeyboardInterruptpath already closes once through_cleanup.Test:
test_extraction_constructor_closes_engine_2107_unit(4 cases):run()raises:close()ran, and the same exception object propagated;read_frame()that raises: the same checks;close()that raisesUnsupportedCall: the originalFormatErrorstill wins;close()is now a no-op.With the source reverted, all 4 fail. The fix(foundation): Extractor keeps its input open when the constructor's run() raises #2100, ownership, extraction, non-seekable and engine tests pass.