Use inspect/1 to safely encode bad binary samples

[mattbaker]

My team finds ourselves in an odd situation.

• We use Absinthe and Absinthe Plug
• A user is (surprisingly) sending us a GET request with their query
• We think that user is sending that in the body of a GET (weird)
• That query appears to have a bad byte in it (0xDF)

The parser correctly fails when it encounters the bad byte, but it also generates an error message with a sample of the input that could not be parsed as a string.

In this case the string it generates is not a valid string because it includes the bad byte. This can cause problems later, for example when absinthe_plug attempts to JSON encode the phase error and send it to the client. In that case the end result is an exception and a 500.

Given the typespec of Absinthe.Phase.Error.message is String.t() I think it's safe to say Absinthe itself should ensure that's the case. The simplest option to me seems to simply run the "sample" we take through inspect/1.

We still preserve useful debugging information by sending back the list of bytes which I consider a good thing personally.

I don't have a strong opinion on the style of the code below, happy to modify it however we see fit. I did opt to only apply this if the string isn't valid so we don't change the way existing errors are formatted.

[mattbaker]

(If this sounds familiar it's similar to #1044 but this time I'm fairly confident the cause is external)

[binaryseed]

💯