-
-
Notifications
You must be signed in to change notification settings - Fork 92
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
If a task returns an exception value, do not raise it in #wait. #270
Conversation
This looks okay to me, although it breaks the behaviour/compatibilty. Can you follow the existing explicit code style We need to be convinced that:
|
Alright.
Thankfully the code makes it pretty clear.
Hopefully there aren't any callers that expect that just returning an exception (or setting it manually with To be really safe there could be a deprecation warning instead. There are callers that expect the exception to be available via #result after a task failed in the test suite though (and those still work fine). |
I think the expectation that
should raise an exception is undefined at best. The fact that existing tests don't break is a testament to that. However, with this PR, can we please add tests to cover the different use cases. In other words, let's not leave it up to chance going forward. Maybe documentation is a good idea too. Thanks! |
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.
LGTM. We might consider backporting this... but honestly, I'm not sure if it matters.
Nah, I don't think so either. |
This also made me think about calling |
That could propagate and stop the calling task (if not caught) right? Should be some other exception instead. But, calling |
I'll have to think about it. Such a change is tricky. |
The `async` gem recently made a breaking API change that was released in patch version 2.6.4.[^1] Following the change, async tasks that return an exception object will no longer raise that exception when `wait` is called. The `Async::HTTP` specs in webmock were written to leverage the old behavior of `wait`. Since async 2.6.4 was released, these specs have been failing in CI. This commit fixes the failing specs by updating how `wait` is used, such that exceptions are still raised as expected in async 2.6.4. This should restore CI to a working state. [^1]: socketry/async#270
Types of Changes
Contribution
Notes
If a task returns an exception value (without raising it),
#wait
raises it.Seems like something that would rarely happen, but it happened to me with an
assert_raises
at the end of a task (apparently, it returns the exception that was raised).