Closed adamrodger closed 2 years ago
Confirmed that if I take the assertion for true
out then the test passes, and the pact file is written correctly. So the FFI calls do work correctly, it's just that they return false
on MacOS, and only on the message
variety of calls.
On the request/response interaction calls they return true
(as verified in other tests) and on both Windows and Linux the message interaction calls return true
, just not on MacOS.
I've had to just disable the FFI return code checking on MacOS when using 0.3.5. That means any actual FFI failures won't be detected, which could cause hard-to-diagnose issues when everything looked like it worked but actually didn't.
There was an race condition I fixed with the Pact handles (852076025500), but I can't see how that would only trigger on the OSX agents. In my case, it only happened on my desktop because CI runs much slower.
I'll create a similar test to see if I can replicate it.
Oh, it might be that pactffi_new_message_interaction
returns a InteractionHandle
, while pactffi_message_expects_to_receive
takes the older MessageHandle
. I get an error in Rust, but in C those would just be type aliases and would look the same.
Actually, pactffi_message_expects_to_receive
does not return a value (it is a void function), so maybe that is why it is different between OSX and Linux/Windows. pactffi_upon_receiving
takes an InteractionHandle
and returns a boolean result.
How did you compile this? I don't know a way to assign or cast the value of a function that returns void.
Anyway, the value of void expressions are explicitly defined as undefined. In J.2 of the public draft of the current C standard:
The behavior is undefined in the following circumstances: [...] An attempt is made to use the value of a void expression, or an implicit or explicit conversion (except to void) is applied to a void expression (6.3.2.2).
And if you're using the assert
macro, it's also undefined if:
The argument to the assert macro does not have a scalar type (7.2).
So looking at the PactNet P/Invoke definitions, it looks like when the messaging FFI methods were added, they were incorrectly added with bool return types instead of void. I assume they were copied and pasted from existing ones that return bool, but I dunno because I didn't do that bit.
I assume they've not changed return type anyway, so they've probably always been wrong. As you say, it's undefined what should happen in that situation so perhaps Windows/Linux return true and MacOS returns false.
I've corrected the PactNet P/Invoke imports so that those messaging methods now return void instead of bool, and that appears to have fixed the issue on MacOS. Sorry for that! I'd never noticed that was originally written with the wrong return types.
FFI Version: 0.3.5
I have a CI run where I've added code that ensures the FFI methods return
true
on those methods which returnbool
, whereas previously it didn't check the FFI response.The CI for this change is failing, but only on MacOS. I've confirmed locally that it passes on Linux and Windows, plus the Linux CI is passing (Windows gets cancelled due to the MacOS failure) but I don't have a MacOS machine on which to confirm the problem. The CI run with trace logs is here though:
https://github.com/pact-foundation/pact-net/runs/7613866358
The test effectively does this sequence of calls via the FFI
If I remove
pactffi_message_expects_to_receive
then the next call to modify the interaction fails instead. It appears that any attempt to modify the interaction just returnsfalse
, but seemingly only on MacOS.On Windows, the logs produce the following:
but on the MacOS logs output, it stops before it gets to the line with
pactffi_message_with_contents
. There doesn't appear to be logging forpactffi_message_expects_to_receive
orpactffi_message_with_metadata
, and those are the calls which fail so it doesn't progress past that point topactffi_message_with_contents