Pact protobuf plugin shows initialization errors but test passes and generates contract

[BartoszLeczycki]

Environment

• Java: JDK 21
• Pact version: 4.6.17 (as seen in generated contract)
• Pact protobuf plugin: 0.5.4 and 0.6.5 (tested both versions)
• OS: macOS
• protoc: 32.0

Issue description

I'm experiencing inconsistent behavior with the Pact protobuf plugin for gRPC contract testing. The plugin appears to fail initialization with connection errors, but the test still passes and generates a contract file.

Specific errors in logs:

12:18:19.177 [main] WARN io.pact.plugins.jvm.core.PluginManager -- args field in plugin manifest is invalid
12:18:19.413 [main] ERROR io.pact.plugins.jvm.core.PluginManager -- Failed to initialise the plugin
io.grpc.StatusRuntimeException: UNAVAILABLE: io exception

Root cause:

Caused by: io.grpc.netty.shaded.io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /[0:0:0:0:0:0:0:1]:63110
Caused by: java.net.ConnectException: Connection refused

Observed Behavior

The strange part is:

1. The logs clearly show that the plugin fails to initialize with connection errors
2. Multiple attempts to connect to localhost ports (63110, 63113) are refused
3. Despite these errors, the test completes successfully and the contract file is generated
4. The generated contract appears to be valid and contains all the expected elements (service definitions, message formats, etc.)

This seems inconsistent with the error messages. I would expect the test to fail if the plugin cannot initialize, but it appears to be working differently.

Test Code Sample

Here's a simplified example showing the test setup:

Consumer Test

@ExtendWith(PactConsumerTestExt.class)
@PactTestFor(
  providerName = "area-calculator-provider",
  providerType = ProviderType.SYNCH_MESSAGE,
  pactVersion = PactSpecVersion.V4
)
@PactDirectory("target/pacts")
public class PactConsumerTest {

  @Pact(consumer = "grpc-consumer-jvm")
  V4Pact calculateRectangleArea(PactBuilder builder) {
    return builder
      .usingPlugin("protobuf")
      .expectsToReceive("calculate rectangle area request", "core/interaction/synchronous-message")
      .with(Map.of(
        "pact:proto", filePath("proto/area_calculator.proto"),
        "pact:content-type", "application/grpc",
        "pact:proto-service", "Calculator/calculateOne",
        "request", Map.of(
          "rectangle", Map.of("length", 3, "width", 4)
        ),
        "response", List.of(Map.of(
          "value", List.of(12)
        ))
      ))
      .toPact();
  }

  @Test
  @PactTestFor(pactMethod = "calculateRectangleArea")
  @MockServerConfig(implementation = MockServerImplementation.Plugin, registryEntry = "protobuf/transport/grpc")
  void calculateRectangleAreaTest(MockServer mockServer, V4Interaction.SynchronousMessages interaction) throws Exception {
    // Test body...
  }
}

Provider Test

@Provider("area-calculator-provider")
@PactFolder("target/pacts")
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class CalculatorGrpcProviderTest {

  @BeforeEach
  void before(PactVerificationContext context) {
    context.setTarget(new PluginTestTarget(
      Map.of(
        "host", "localhost",
        "port", 6565,
        "transport", "grpc"
      )
    ));
  }

  @TestTemplate
  @ExtendWith(PactVerificationInvocationContextProvider.class)
  void verify(PactVerificationContext context) {
    context.verifyInteraction();
  }
}

Proto

syntax = "proto3";

package area;

service Calculator {
  rpc calculateOne (ShapeMessage) returns (AreaResponse) {}
}

message ShapeMessage {
  oneof shape {
    Rectangle rectangle = 1;
  }
}

message Rectangle {
  float length = 1;
  float width = 2;
}

message AreaResponse {
  repeated float value = 1;
}

Additional troubleshooting performed

• I've tried running with both plugin version 0.5.4 and the latest 0.6.5
• I can verify the plugin executable runs correctly when invoked directly from command line
• I've tried creating the log directory manually at ~/.pact/logs
• I've tried using absolute paths for both proto files and output directories
• I've used System.setProperty("pact.writer.overwrite", "true") to force overwrite of existing files
• I've upgraded protoc from version 29.3 to 32.0

Questions

1. Is this expected behavior? Should we ignore these initialization errors if the contract is being generated successfully?
2. What could be causing the connection refused errors when trying to connect to localhost ports?
3. Are there known issues with the plugin manifest (seeing "args field in plugin manifest is invalid" warnings)?
4. Is there a configuration that would eliminate these warning/error messages?
5. How does Pact determine which plugin version to use when multiple versions are installed?
6. What's the recommended approach to ensure a specific plugin version is used?
7. Could there be potential issues with the generated contract despite the test passing?

Any help would be greatly appreciated, as these error messages are concerning even though the test appears to be working.

[YOU54F]

Hey @BartoszLeczycki,

Apologies for the late reply!

Is this expected behavior? Should we ignore these initialization errors if the contract is being generated successfully?
What could be causing the connection refused errors when trying to connect to localhost ports?

I wonder if the error is because it is trying ipv6 first and falling back to ipv4, meaning the error is not fatal and why it ultimately passes

Are there known issues with the plugin manifest (seeing "args field in plugin manifest is invalid" warnings)?

args are optional in the pact-plugin manifest, the pact protobuf plugin does not require them, so the key is not set in the json

https://github.com/pactflow/pact-protobuf-plugin/releases/download/v-0.6.5/pact-plugin.json

this should be a non-issue as the args param is only relevant if the author decides it needs to be, and for the protobuf plugin, it is not

Is there a configuration that would eliminate these warning/error messages?

I don't believe so, not a simple one that is exposed. You could suppress in a log filter, or propose a change to the core library.

How does Pact determine which plugin version to use when multiple versions are installed?

on the consumer side, the consumer explicitly sets the version to be used in the test.

on the provider side, the plugin version is read from the pact file

this topic provides some insight into how it works with the semver versions, and it's impact in reality

pact-foundation/pact-plugins#21

What's the recommended approach to ensure a specific plugin version is used?

Set the latest version you require on the consumer test, if there is a patch or minor version released, and the pact-plugin index has been updated with the plugin details, both the consumer and provider will use the latest versions, to the best of my knowledge.

might need to give that a quick test out, as it's been a while. It is probably the same as reported in my previous post, and feel free to chime on the other post or this one

pact-foundation/pact-plugins#33

technically the ffi doesn't require you to specify a plugin version, in which case it will always use the latest known version from the index, at the time of execution afaik