I've just raised a new FFI issue for a breaking change: https://github.com/pact-foundation/pact-reference/issues/196 I think it's really important as we want more and more libraries to be shipping on top of the FFI to have a really good regression test suite at the 'black box' level (i.e. using the FFI library itself from another language) and also to communicate breaking changes really clearly with maintainers. There has been no discussion on this channel about the change beforehand, no impact assessment/statement, no guidance on what to look out for afterwards, and I think we need to fix that. I think we need a more mature process around evolving the FFI and maintainers need to be a big part of that discussion. I just happened to notice that it had made logging unusable, and people are going to come to rely on that because they can't just set a breakpoint in their code or whatever, because it now all crosses an FFI boundary. This is the type of thing we need to discuss beforehand so that maintainers are aware they need to check things after upgrades, and ideally this should be found long before the FFI is released and people start upgrading to it. The big problem with the FFI approach is that the bugs will ultimately be reported at the client library level instead of in

pact-reference

itself. If I would've missed that and shipped it, the bug reports would've been raised against PactNet, even though nothing in PactNet changed and the fix doesn't need to be made to PactNet. This hurts the reputation of PactNet, me personally, and the pact ecosystem as a whole, despite it being something generally outside of my control. I apologise that that's a bit of a rant, but it's very frustrating to be surprised like that and I think we need to define an approach going forwards which prevents those surprises.

Really fair comments @Adam Rodger (pact-net) - Rants are welcome, it is a safe space here. We do need to and have a duty to make sure the developer experience is on point for maintainers, as it can have direct and very real impact on end users who are using our libraries to protect their deployments. Appreciate your eagle eye, and I also noted an issue you raised against the pact-specification today aswell. Will take some time to digest, discuss and get something open arranged for us to attend, collect thoughts, agree a path forward. Apologies for the inconvenience!

There are actually a number of tests/examples for the FFI interface (including some c tests e.g. https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_ffi/examples/logging/src/main.c). But I think this behaviour is not included in that. I think it would be a good opportunity to revisit the test strategy here. We have discussed the idea of a BDD suite here that shows what the FFI does (ideally, there is also a standard client BDD test suite we have also that can be used to test each language. This could also work as a nice up-to-date feature matrix table)

@Adam Rodger (pact-net) can you please stay on the 0.2.x version. I'll let you know when 0.3.x is ok to use

(+1 for structured logging! 🙂)

I don't think structured logging solves the problem, because then that just pushes the problem of parsing and displaying it onto every client library. We want a consistent report in all the client libraries, and our method for that is to do it in the shared FFI. I can't stress enough how important these logs are. I've just migrated a codebase with 2283 consumer tests, where 68 were falling after the upgrade. I had to use the logs extensively because there are a number of breaking changes to track down, and the logs are the only place that give you the info you need to work that out. In my case, most of the failures were because the Ruby library doesn't validate query string parameters whereas the Rust library does. We had a few tests where the client sends a query parameter but the setup didn't include it, so now those tests fail. The logs are the only way you can find that out.

😞 I'm not quite sure where the last year went, I still have on my to-do list progressing looking at how the different libraries get logs and what they look like for useful filtering etc following a conversation with Tim I will actually get time at some point 😮I struggled a bit with the overhead of getting a similar example for each language to get anything meaningful Getting a bit closer 👋 @Yousaf Nabi (pactflow.io) 😀

We might want to find a way to open this discussion up and maybe get some face time together. There appears to be a few collaborators who are existing maintainers, long time contributors, or new contributors who are getting involved in different parts of the estate and would be good to get a round table. I can see some work @Lewis Cowles has been doing across various repos, so is offering fresh insight with some sensible ideas for long term maintainence which are worth surfacing somewhere. I know this is diverging slightly from the actual logging issue but might allow us to take a wider lense view of the estate as a whole. Just spitballing • agree on a central place to collab • Drop in sessions across different tz’s to allow video communication as well as async communication proper Diagram of the dependency graph of doom • target state • Gap analysis Definitely worth getting the input and thoughts of other maintainers, contributors and users here as there will be such valuable insight and potential actionable items, that I can help coordinate

What do we need to do to resolve these issues? One thing I have been thinking of is splitting out the FFI into it's own repository. That way we could hand it over to this group to manage, and I can step away to focus on other areas. The plugin and gRPC work is now nearly complete (which is what I have been focusing on the last 6 months). I just need to get an example project working via FFI (hence the recent change which required a new function), then there are no more plans to change anything else.