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

Add response body to network errors #3714

Merged
merged 13 commits into from Jul 21, 2020

Conversation

Ericson2314
Copy link
Member

@bburdette So we've gotten the new field into the error message after much wrangling, but I wasn't quite sure what to do next, and I thought it might be a good time to solicit your advice anyways.

This was introduced in fa125b9, and
then "reverted" in 1cf4801, except that
revert left the struct around doing nothing useful.

We're removing it all the way now because we want to make a new
`TeeSink` complementing the already-exiting `TeeSource`, that is
actually a completely different concept as far as the class hierarchy is
concerned.
This is a bit complex because we want to expose extra functionality the
wrapped class has. Perhaps there is some inheritancy trickery to do this
nicer, but I don't know it, and this is the first thing we tried after a
series of attempts that did build.

This design is kind of like that of Rust's Writer, Reader, or Iter
adapters, which impliment more traits based on what the inner type
implements.
Everywhere seems to use `getHTTPStatus` now.
@Ericson2314 Ericson2314 marked this pull request as draft June 17, 2020 22:39
@bburdette
Copy link
Contributor

Ok, so the response is a member of the FileTransferError exception. Do you plan on the response showing up as part of the message the user sees when the FileTransferError is handled? Or will it be used for something else, like the error member? If its only for the message, you could put it in as a regular value in the string template, something like:

throw FileTransferError(Interrupted, "%s of '%s' was interrupted\nresponse was: %s", 
                                     request.verb(), request.uri, response));

But I'm guessing the purpose off the response field is something else, in which case LGTM.

@Ericson2314
Copy link
Member Author

I was thinking maybe just show it on higher verbosity levels. I was also reminded of you making SysError store the errno, rendering it on demand. I like it when structured errors and nicer messages are complementary.

@bburdette
Copy link
Contributor

I don't really have a plan as yet for varying amounts of error detail depending on verbosity, but you could do that in the FileTransferError constructor if you're building the hint message there. SysError takes this both-ways approach of saving the errno and embedding it into the hint in its constructor, though without any verbosity checks.

We have a larger problem that passsing computed strings to the first
variable argument of many exception constructors is unsafe because that
first variable argument is interpreted not as a plain string, but format
string, and if it contains '%' boost::format will abort, since there are
no arguments to the format string.

In this particular instance '%' was used as part of an escape code in a
URL, which, when the download failed, caused Nix to abort displaying the
`FileTransferError`.
@Ericson2314 Ericson2314 changed the title WIP: Add response body to network errors WIP: Add response body to network errors --- contains #3720 Jun 18, 2020
@Ericson2314
Copy link
Member Author

Included #3720 as I needed that to be able to verify this. (My best source of 500 errors used escaped / in URLs.)

 - Bad dynamic cast target ...classic

 - std::shared_ptr need explicit deref
@Ericson2314 Ericson2314 changed the title WIP: Add response body to network errors --- contains #3720 Add response body to network errors --- contains #3720 Jun 18, 2020
@Ericson2314
Copy link
Member Author

OK I did it just like SysError, storing the hint and the original value, and not bothering to look at verbosity as this sort of error is very rare.

@Ericson2314 Ericson2314 marked this pull request as ready for review June 18, 2020 19:05
@Ericson2314 Ericson2314 changed the title Add response body to network errors --- contains #3720 Add response body to network errors Jun 21, 2020
@Ericson2314
Copy link
Member Author

I added a bunch more stuff to #3720, so I don't think it makes sense to block this on that just cause they contain a commit in common, hence the rename.

: Error(args...), error(error), response(response)
{
const auto hf = hintfmt(args...);
if (response) {
Copy link
Member Author

Choose a reason for hiding this comment

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

Only do this under higher verbosity (-vvvv). Or Body is "not HTML", we can use some heuristic for that.

Without enough -vvvv, we can also adjust this message so the user knows whether they can try again and get more info, or there wasn't an error message anyways.

Due to NixOS#3841 we don't know how print
different messages for different verbosity levels.
Comment on lines +848 to +850
// FIXME: Due to https://github.com/NixOS/nix/issues/3841 we don't know how
// to print different messages for different verbosity levels. For now
// we add some heuristics for detecting when we want to show the response.
Copy link
Member Author

Choose a reason for hiding this comment

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

@edolstra We got stuck trying to make it respect -vvv, and opened up #3841 in response. Perhaps the heuristic with no way to override is good enough for now.

@Ericson2314
Copy link
Member Author

OK CI is fixed.

@edolstra edolstra merged commit 0951330 into NixOS:master Jul 21, 2020
@Ericson2314 Ericson2314 deleted the add-body-to-network-errors branch July 21, 2020 16:32
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

4 participants