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
DefaultHTTPErrorHandler should use errors.As() instead of type assertion on HTTPError #2228
Conversation
danielbprice
commented
Jul 21, 2022
- Helps consumers who want to wrap HTTPError, and other use cases
- Added testing for HEAD requests which produce errors
Codecov Report
@@ Coverage Diff @@
## master #2228 +/- ##
==========================================
+ Coverage 92.34% 92.44% +0.09%
==========================================
Files 37 37
Lines 3123 3123
==========================================
+ Hits 2884 2887 +3
+ Misses 150 149 -1
+ Partials 89 87 -2
Continue to review full report at Codecov.
|
For what it's worth, I think this change is much scarier than the previous one I submitted, in #2227, but the overall thrust is the same. Totally understand if this seems too risky, maybe it could go into v5 instead (I don't really know). If you have additional testing I should do, or ideas of how I could raise confidence, let me know. |
I think this would be OK if that |
Ok, I think I misunderstood what that code was trying to do. I'll take another lap. |
Just so I understand: the desired behavior is that if an HTTPError has another HTTPError inside of it, then we want to use the inner HTTPError as the "result" of the HTTP call and that error sets the Status code? This case is sadly not covered by the current test suite: It would be so helpful to have a sense of how this might occur. Does it have to do with Middleware somehow? The modern thing would be to call "As" again, searching down the chain, but maybe it's only about the directly nested error? I would think that if this was a concern, the right thing would be to loop to find the innermost HTTPError. This behavior seems odd to me and not what I guess I would expect, but I can preserve it. The commit which introduced this doesn't give any real hints that I can see: ecc01d2 If we could understand this better, I could write some test cases for it as well. |
Here's a short test which shows how strange this behavior is:
If you run it:
What seems so confusing to me is that this isn't documented anywhere, and code like HTTPError.Error() doesn't follow this protocol. Would you accept a PR to drop this behavior in V5? |
Argh. I see that this code has also changed in v5 to some degree; let me know, I can try to sync up with that more closely. Lines 314 to 322 in 7402266
|
5379984
to
16d3b65
Compare