search

pact-foundation / pact-net

.NET version of Pact. Enables consumer driven contract testing, providing a mock service and DSL for the consumer project, and interaction playback and verification for the service provider project.
https://pact.io
MIT License
823 stars 225 forks source link

Using signs outside ASCII in response body #468

Open dominikjeske opened 11 months ago

dominikjeske commented 11 months ago

I'm testing pact-net and I spotted weird behavior when using signs outside ASCII table. I was using my native letters from my country Poland (like ł,ó,ń) - they are UTF-8 compatible but when I'm using them in WithJsonBody mock that is used under the cover is returning empty body. I cannot find in documentation is this by design or is it bug. I suspect some but when interop with native library is used.

adamrodger commented 11 months ago

Yeah that sounds like interop problems would be the first thing to check. We should definitely have some tests using non-ASCII characters and we don't, so that's the first thing to add.

On Sat, 15 Jul 2023, 17:44 Dominik Jeske, @.***> wrote:

I'm testing pact-net and I spotted weird behavior when using signs outside ASCII table. I was using my native letters from my country Poland (like ł,ó,ń) - they are UTF-8 compatible but when I'm using them in WithJsonBody mock that is used under the cover is returning empty body. I cannot find in documentation is this by design or is it bug. I suspect some but when interop with native library is used.

— Reply to this email directly, view it on GitHub https://github.com/pact-foundation/pact-net/issues/468, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD4FKQTKYXME3AX6SIG3B3XQLCINANCNFSM6AAAAAA2LMLMWI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

adamrodger commented 11 months ago

I've tested this out locally and it breaks pretty badly with non-ASCII characters in things like consumer/provider names, interaction names, provider states, etc. It generally seems to fail everywhere because the FFI reports invalid UTF-8.

That's a bit of a problem given C# strings are UTF-16 and the P/Invoke options are just "Unicode". We may have to marshall strings manually or something.

You also get completely garbled responses back when you try to use the Unicode option to retrieve things like server logs:

image

The difference is that I get errors whereas you report that the test passes but then silently contains no data. I've not managed to reproduce that, although I could definitely see that being a possibility.

I can only apologise for that, and recommend that in the meantime you only use ASCII characters until the issue can be resolved.

adamrodger commented 11 months ago

The linked PR fixes the issues on Windows, but is writing unreadable chars on Linux, so not sure what's happening there.