Skip to content
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

Try with timeout rethrow #942

Merged
merged 1 commit into from Oct 25, 2022

Conversation

gustafsson
Copy link
Contributor

The previous behaviour was to return any exception as res which I believe was a bug.

@gustafsson gustafsson force-pushed the try_with_timeout-rethrow branch 2 times, most recently from 4d348cb to 0fe4356 Compare October 18, 2022 08:45
@quinnj
Copy link
Member

quinnj commented Oct 18, 2022

Hmmm, can you clarify the issue you're seeing that's prompting the changes here? I'm not sure I follow your PR description details.

@gustafsson
Copy link
Contributor Author

The wrapped function f in try_with_timeout may throw. For any reason outside the control of try_with_timeout.

When f throws an excpetion e and the condition is notified with notify(cond, e) we'll pick it up on the parent task with res = wait(cond). res will now refer to e which then gets returned with return res.

By changing notify(cond, e) to notify(cond, e, error = true) the exception will be rethrown on the parent task by res = wait(cond) instead.

Effectively this means that a pattern like this (for instance in sslupgrade) behaves the same with respect to exceptions from f.

res = if timeout > 0
        try_with_timeout(.., timeout, ..) do
            f(args...)
        end
    else
        f(args...)
    end

@gustafsson gustafsson force-pushed the try_with_timeout-rethrow branch 4 times, most recently from b592770 to 618dab2 Compare October 18, 2022 21:39
The previous behaviour was to return any exception as res.
@codecov-commenter
Copy link

codecov-commenter commented Oct 18, 2022

Codecov Report

Merging #942 (618dab2) into master (2377beb) will decrease coverage by 0.45%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #942      +/-   ##
==========================================
- Coverage   80.44%   79.98%   -0.46%     
==========================================
  Files          36       36              
  Lines        2950     2953       +3     
==========================================
- Hits         2373     2362      -11     
- Misses        577      591      +14     
Impacted Files Coverage Δ
src/Exceptions.jl 94.59% <100.00%> (+3.41%) ⬆️
src/HTTP.jl 73.33% <0.00%> (-13.34%) ⬇️
src/clientlayers/RetryRequest.jl 75.60% <0.00%> (-2.44%) ⬇️
src/connectionpools.jl 72.72% <0.00%> (-1.02%) ⬇️
src/ConnectionPool.jl 86.69% <0.00%> (-0.86%) ⬇️
src/Messages.jl 86.39% <0.00%> (-0.60%) ⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@gustafsson
Copy link
Contributor Author

If I recall corretly I ran into this a while back when the connection was closed during sslupgrade and something in MbedTLS threw an exception that didn't get rethrown by try_with_timeout.

@@ -33,29 +33,33 @@ function try_with_timeout(f, shouldtimeout, delay, iftimeout=() -> nothing)
notify(cond, f())
catch e
@debugv 1 "error executing f in try_with_timeout"
notify(cond, e)
isopen(timer) && notify(cond, e, error = true)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to check isopen(timer) here? It seems like it wouldn't matter whether it's open or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

iftimeout() may cause f to throw. In that scenario I'd rather pick up the TimeoutError in wait(cond) and swallow the exception from f

@quinnj quinnj merged commit bfcc80a into JuliaWeb:master Oct 25, 2022
@gustafsson gustafsson deleted the try_with_timeout-rethrow branch October 26, 2022 12:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants