-
Notifications
You must be signed in to change notification settings - Fork 87
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
Test cleanups for timeout and async usage #416
Test cleanups for timeout and async usage #416
Conversation
This way the user doesn't just see `Nothing`, but gets the information that this may be a transient failure.
Made possible by changing `runTLSPipeN` so tat the data to feed is pre-generated in `PropertyM`, and then the whole server spawning and data feeding is done in one `run` IO block. (`PropertyM` is a continuation monad, which does not permit guaranteed scoped freeing of resources like the fake server.)
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.
Excellent!
This PR modified how the test suite reports failures. Example before:
Now becomes:
|
If no better solution, could those changes be reverted please? |
@ocheron Sorry, I didn't understant from your previous comment in #416 (comment) that there was a problem; it looked like just a remark, not like an issue, so I didn't reply at that time.
I still don't quite understand what the problem is though / which code was broken. Do you mean that after this change, the What this PR did is to make it such that only the first error of client or server is raised, and the respective other thread is killed. I thought that this was the inteded behaviour, so that you get onl the first error message, and not other errors that may be caused by the first one but are not the root causes. If you would like to get both the client and the server errors, the correct solution is most likely to change let readResult = waitBoth cAsync sAsync >> readChan resultQueue
cont (writeChan startQueue, readResult) into something like let readResult = do
eClientRes <- try $ wait cAsync
eServerRes <- try $ wait sAsync
case (eClientRes, eServerRes) of
(Right _clientRes, Right _serverRes) -> return () -- no error
(Right _clientRes, Left serverErr) -> throwIO serverErr -- only the server errored
(Left clientErr, Right _serverRes) -> throwIO clientErr -- only the client errored
(Left clientErr, Left serverErr) -> throwIO serverErr $ ... -- make an exception here that contains both the client and server errors
readChan resultQueue
cont (writeChan startQueue, readResult) Is this what you are after? |
Clearly that would be an improvement w.r.t. the level of details reported after a failure. But the intent is also to handle a scenario where one side fails and the other side hangs because it never receives the message it expects. |
@ocheron That's what should be happening with this PR merged though -- did you observe that to not work? |
If I summarize my requirements:
Then:
|
Sorry, I had forgotten to delete the line A global test timeout should be easily addable with the |
That will do property (b) but not (a): Package Property (a) + (b) together is all about keeping one child thread running, so not |
If promptly means "immediately", you can really only get 1 of (a) and (b): Either you wait until one side fails and cancel the other one, or you wait until both sides fail. If promptly means after some timeout, then I think you could just do let readResult = timeout yourTimeout $ do |
So it's a negative answer about the revert. |
Minor test cleanups for #413 and #286.
CC @ocheron