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.
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.
This single test fails with "AssertionError: ConnectionError not raised" and I am not sure why. With this patch, sendfile is not called if an offset is too high, which is slightly different from other platforms where it is called and sends nothing; but I don't think that causes this issue.
It seems to me that the entire message is sent and
close_afterdoesn't work as expected. But I don't see into asyncio internals that much, so it's just a guess.It was failing before as well, so it doesn't seem to be a regression. If you have any idea why that might be the case, how to test it further, or how to fix that, I will gladly do so (I don't really want to skip it).
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.
Yeah, I don't like skipping it either. Unfortunately I won't be able to assist with the debugging, but if you have time please try to figure this out.
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 am getting closer. It looks like no matter the
BUF_SIZE,sendfilealways sends at least131072bytes, so it sends everything before transport is closed and hence noConnectionErroris raised. If I understand it correctly, the intended behavior is to limitsendfileto send at maximumBUF_SIZEbytes, meaning that transport is closed long before everything is sent (correct me if I'm wrong). I found out that the test passes ifDATAsize is doubled.My guess is that this might be a difference in how Solaris handles those buffer limits; I will keep digging.
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 believe I found the culprit - the reason is that as per documentation: "At present, lowering SO_RCVBUF on a TCP connection after it has been established has no effect". This is on Oracle Solaris, but the bug is old enough that it should be present in all OpenSolaris forks unless they fixed it themselves.
I don't know If you'd prefer having it skipped here for all Solarises or if we should skip it internally since it is an OS bug, not a difference (I think that both are valid).
I checked Illumos source code and I believe they are also affected by this
SO_RCVBUFrelated bug (but I might have missed their fix somewhere where I was not looking and I cannot verify that on Illumos machine).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.
Let's skip the test on Solaris and add an elaborate comment why, basically summarizing