-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BF: don't write output from within sshrun #7072
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a plain removal of these lines is not good. It is all but clear that there could not be any output to write from the code in this file. We are doomed to swallow something important at some point.
If this assertion hold (and needs to hold), an assertion should be in place.
But why not simple guard the write call, and turn it into a best-effort attempt? If a pipe is closed, it wont matter, it could not go anywhere anyways. But of it is open, and there is something, it will come out.
And this seems better than an assertion that does not hold, as it will leave the user with a crash.
WDYT?
@mih : Well, I could do that obviously, but I don't see why. Edit: The only reason I can see, how it's "all but clear that there could not be any output to write from the code" is, that the behavior of the |
Codecov ReportBase: 74.76% // Head: 75.90% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## maint #7072 +/- ##
==========================================
+ Coverage 74.76% 75.90% +1.13%
==========================================
Files 354 354
Lines 58945 58940 -5
Branches 6310 6310
==========================================
+ Hits 44072 44736 +664
+ Misses 14858 14189 -669
Partials 15 15
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Added documentation is essential. Other than that I think the new implementation is as problematic re wrong assumptions about behavior as the one before. Your rational is based on assertions that are not in the code. Anyways, no need to convince me. |
I honestly don't understand what that assertion is. The now documented behavior of To me it's kinda the opposite. If I in 6 months time see
I wonder how long it will take me to realize again, that with current implementation there can't be anything in that May be I'm not seeing something. I really don't know what it is. WDYT, @datalad/developers ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my thinking about it -- I think we better assert
the assumptions of the code especially if there was prior code thinking otherwise
`datalad sshrun` explicitly calls SSH with `log_output=False` which results in the use of `NoCapture` protocol with the runner. Meaning, stdout/stderr of SSH is written out anyway already. When SSH returns, `sshrun` tried to write both to its stdout/stderr. But: It could not possibly have anything to write. That would not be an issue in and of itself, but `sshrun` is not necessarily used directly. In particular it is called by `git` (due to `GIT_SSH_COMMAND=datalad sshrun`). This resulted in a problem when apparently `git` has closed the pipe to its ssh executable (`sshrun`) already and we tried to write to it (although we really didn't even have something to write). This ultimately led to issue datalad#6599, where the actual `ssh ... git-upload-pack` execution succeeded and returned 0, but `datalad sshrun` itself produced a broken pipe error trying to write to stdout and hence returning non-zero. It's not entirely clear when exactly this happens. It may be depend on git version when the pipe is closed as the failing builds are running 2.35.1 (MacOS on appveyor) whereas otherbuilds have either newer or older versions of git. In any case: There can't be anything to write out to begin with, so don't even try. Also: Make it clear in the code, that and why we don't expect any captured output from the SSH subprocess by not storing the empty return value, so future changes (and debuggers) don't falsely assume that 1. Output can simply be captured (with existing protocols) or 2. The returned value would currently be of any use simply b/c it's there. (Closes datalad#6599) (Closes datalad#7078)
Thank you @bpoldrack - let's proceed! |
PR released in |
datalad sshrun
explicitly calls SSH withlog_output=False
which results in the use ofNoCapture
protocol with the runner. Meaning, stdout/stderr of SSH is written out anyway already. When SSH returns,sshrun
tried to write both to its stdout/stderr. But: It could not possibly have anything to write. That would not be an issue in and of itself, butsshrun
is not necessarily used directly. In particular it is called bygit
(due toGIT_SSH_COMMAND=datalad sshrun
). This resulted in a problem when apparentlygit
has closed the pipe to its ssh executable (sshrun
) already and we tried to write to it (although we really didn't even have something to write).This ultimately led to issue #6599, where the actual
ssh ... git-upload-pack
execution succeeded and returned 0, butdatalad sshrun
itself produced a broken pipe error trying to write to stdout and hence returning non-zero.It's not entirely clear when exactly this happens. When exactly the pipe is closed may be depend on git version as the failing builds are running 2.35.1 (MacOS on appveyor) whereas otherbuilds have either newer or older versions of git. In any case:
There can't be anything to write out to begin with, so don't even try.
Closes #6599
Closes #7078