Open lextiz opened 5 years ago
Fix proposal: wrap JSON parsing in a try/catch block, when parsing would fail than the object that is printed for debugging purposes would not be pretty printed, but the transaction would not fail. Would such a fix be accepted as PR?
Hm... I'm really not sure how a zip file would work. How would it get written into the JSON file?
What I am trying to do is to use pact stub server to return a response to a POST request, that has binary body. The attempt to encode a go object (that contains also the binary payload) to JSON and back comes from pretty_generate
function, that is used only to beautify the debugging printouts. So the proposal is to wrap this logic in a try/catch block, so the transaction would not fail when pretty printing of the debug logs fails.
I still don't think this is going to work. How do you expect the binary data to be encoded in the UTF-8 encoded json pact file?
That works for me fine, because this data is not written to a JSON file. I am not running any assertions on the binary data (except that it exists), I just want pact-mock_service not to crash when it receives a request with non-UTF-8-encodable data. I do not think that running assertions on the binary data, that would require writing it to a JSON file is a good idea in general.
I've just come across this issue when creating a pact-test that involves uploading a pact file with a binary upload.
I found it also erroring at the same point as you, although I have had to use rescue Encoding::UndefinedConversionError
begin
JSON.pretty_generate(JSON.parse(object.to_json))
rescue JSON::ParserError
object
rescue Encoding::UndefinedConversionError
object
end
I am not sure if pact is going to work for my current use case (mutlipart/form-data) but spiking it today
Released in 3.1.1
@lextiz does this solve your issue now? I need to try it out at work tomorrow
@YOU54F I have tested the fix "in-place" only by replacing the ruby code in live environment and checking the API behavior, without releasing the whole library. The 3.1.1 version was not tested by me yet.
I am trying to stub a response for a PUT request that has a zip file as a payload. As far as I understand from the documentation this is a valid use case. However the stub server responds with 500 code and has the following stack trace in logs:
Am I missing something or the stub server expects JSON payload for all interactions?
The root cause of this specific failure is that encode method fails to encode some payload as UTF-8, is that is not meant to be interpreted as such. In my case no validations for body are needed, is that possible to bypass the failing code by having a different contract?