Unexpected content in AsynchronousMessage

[phooijenga]

We have a series of tests that boil down to the following:

mockProvider.
	AddAsynchronousMessage().
	Given("something happens").
	ExpectsToReceive("a notification").
	WithContent("application/json", eventJSON).
	ConsumedBy(handleWrapper).
	Verify(t)

We have had some of them intermittently failing. The consumer function (or Pact, if we use AsType) is unable to parse the AsynchronousMessage.Contents, usually failing with an error similar to invalid character '\x01' after top-level value.

In one particularly interesting case, we found that there was a complete SQL statement included in the message contents.

I think the root cause of the problem lies in Message.WithContents, which seems to assume that a byte slice can be safely cast to a *C.char. As far as I know, Go makes no guarantees that a slice is NUL terminated.

[YOU54F]

Hey @phooijenga,

How are you generating your eventJSON as a byte[]?

Are you using https://pkg.go.dev/golang.org/x/sys/unix#ByteSliceFromString?

Do you think we should be checking if the string in NUL terminated, and terminate if not, or return a error to the user to ensure that they null terminate?

[phooijenga]

I'm using the standard json.Marshal.

It would probably work if you convert the byte slice to a string first, and then use CString (like it already does for the contentType) to pass the value to the FFI function:

func (m *Message) WithContents(part interactionPart, contentType string, body []byte) *Message {
    cContentType := C.CString(contentType)
    defer free(cContentType)

    cBody := C.CString(string(body))
    defer free(cBody)

    res := C.pactffi_with_body(m.handle, C.int(part), cContentType, cBody)
    log.Println("[DEBUG] response from pactffi_interaction_contents", bool(res))

    return m
}

However: it would probably be better to update WithContents to take a string body to match the FFI function (which also requires the body to be valid UTF-8).

[YOU54F]

sorry for late reply,

I agree with the proposed fix, and I am fairly sure we have seen that issue intermittently in our test suite.

However: it would probably be better to update WithContents to take a string body to match the FFI function (which also requires the body to be valid UTF-8).

That might make sense but would be a breaking interface change. We use the same pattern as in your fix, in other areas where we use pactffi_with_body