Close owned transfer files when the channel closes with an error - #89
Open
OskarEichler wants to merge 1 commit into
Open
Close owned transfer files when the channel closes with an error#89OskarEichler wants to merge 1 commit into
OskarEichler wants to merge 1 commit into
Conversation
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.
Summary
Close library-owned upload/download files in an ensure clause when a channel closes, including when exit-status validation raises. Leave caller-owned IO open.
Reproduction and evidence
Closes #20. A download receiving
C0644 6 fileopens its destination; a subsequent nonzero channel exit raises Net::SCP::Error but previously left that file descriptor open. The public-entrypoint channel simulation now observes the original error and a closed file. Additional models cover upload/download, nonzero/missing exit status, already closed files and caller-owned File/StringIO behavior.Compatibility / breaking changes
No API or dependency change; existing transfer errors remain errors. This handles channel-close cleanup, not all exceptions from user progress callbacks or an abandoned channel that is never closed. No broader lifecycle guarantee is claimed.
Verification and limits