Nested arrayContains reifies to null in generated body (bundled pact_ffi 0.4.7)

[mkieselmannPDG]

Summary

An arrayContains matcher that is nested inside another arrayContains reifies to null in the generated mock-server body, instead of to a concrete array. Strict consumer-side decoding of that body then fails. Top-level arrayContains works correctly; only nesting is affected.

The root cause is in the bundled pact_ffi (0.4.7), not in the Swift layer.

Environment

• Bundled FFI: pact_ffi 0.4.7, pact_models 1.1.9 (read from PactSwiftMockServer.xcframework)
• Dependency chain: PactSwift → PactSwiftServer 0.4.7 → PactMockServer 0.1.2 (the libpact_ffi xcframework)
• Discovered while using a fork that adds an arrayContains matcher (pepejeria/PactSwift@feat/array-contains-matcher), but the underlying defect is in the bundled FFI and affects the whole surpher stack.

Root cause

In pact_ffi 0.4.7, rust/pact_ffi/src/mock_server/bodies.rs → process_object, the example body for an arrayContains matcher is generated by re-processing its variants array with skip_matchers = true:

let (value, skip_matchers) = if let Ok(rule) = &matching_rule {
  match rule {
    MatchingRule::ArrayContains(_) => (obj.get("variants"), true), // reprocess variants, skip_matchers = true
    _ => (obj.get("value"), false)
  }
} ...;

Under skip_matchers = true, any object carrying pact:matcher:type is reified only from its "value" key:

} else { // skip_matchers == true
  match obj.get("value") {
    Some(val) => ...,
    None => Value::Null   // <-- an arrayContains object has no "value" -> null
  }
}

An arrayContains matcher serialises as { "pact:matcher:type": "arrayContains", "variants": [...] } with no "value" key. So:

• Top-level arrayContains works — reached via the non-skip path, which reads variants.
• Nested arrayContains collapses to null — reached only via the skip-matchers path, which looks for "value" and finds none.

Already fixed upstream

In pact_ffi ≥ 0.4.9, process_matcher was refactored so the arrayContains branch recursively builds its example from variants and returns Value::Array(json_values), independent of any "value" key. On that version nested arrayContains works with no client change. So bumping the bundled libpact_ffi (via PactMockServer / PactSwiftServer) to ≥ 0.4.9 is the clean fix.

Reproduction

An end-to-end consumer test with a nested arrayContains, run against the real mock server:

try response.jsonBody(
    .arrayContains([
        [
            "id": .like("outer-1"),
            "children": .arrayContains([
                ["childId": .like("inner-1")],
            ]),
        ],
    ])
)

Fetch the generated body inside builder.verify { ... } and inspect it:

• Actual (0.4.7): the top-level array is present, but children is null.
• Expected: children is a non-empty array ([{ "childId": "inner-1" }]).

Proposed fixes

Bump the bundled libpact_ffi to ≥ 0.4.9 in PactMockServer / PactSwiftServer, where arrayContains example generation is recursive and no longer depends on a "value" key.

[pepejeria]

@mkieselmannPDG's analysis of the bug looks right to me. But I don't think this is a pact_ffi bug that needs fixing: PactSwift's mock server dependency (PactSwiftMockServer) points at a stale fork, and that fork ships an old pact_ffi. The XCFramework published in this org already has the fix.

Two things:

• The bundled FFI is 0.4.0, not 0.4.7. PactSwift points at ittybittyapps/PactSwiftMockServer on branch: "main" (Package.swift:22). That fork's libpact_ffi.version says 0.4.19, but the xcframework it ships hasn't been rebuilt since 2023-01-13, and is really 0.4.0. So the version file is just wrong.
• surpher/PactSwiftMockServerXCFramework v1.1.1 already ships pact_ffi 0.4.25, which has the fix. So anyone using the published XCFramework shouldn't hit this.

What needs to be done

To properly fix this:

1. Depend on the official build, not a third-party fork. Right now PactSwift gets its mock server from ittybittyapps/PactSwiftMockServer (pact_ffi 0.4.0, last built 2023). It should come from surpher/PactSwiftMockServerXCFramework v1.1.1 (pact_ffi 0.4.25).

   On Apple platforms that means a .binaryTarget, since PactSwiftMockServer/Package.swift is Linux-only and says so itself ("Use the following in PactSwift > Package.swift"). So PactSwift/Package.swift:22 would drop the ittybittyapps dependency and use:

   .binaryTarget(
     name: "PactSwiftMockServer",
     url: "https://github.com/surpher/PactSwiftMockServerXCFramework/releases/download/v1.1.1/PactSwiftMockServer-v1.1.1.zip",
     checksum: "a5bb088c0b3f6a155013954f0d59c88557c70e4653ba819fbb796b63945b3a86"
   ),

   (I checked the checksum with swift package compute-checksum and it matches the published .checksum file.)

   This pins one exact release instead of a moving branch, which is how the old binary went unnoticed for so long. It needs some small API changes, because the fork and upstream have drifted apart. No Rust rebuild and no FFI change.

Some cleanup in surpher/PactSwiftMockServer. Not needed to fix this issue, but it's why this happened:

2. Revert c749c42. I saw this one landed already, I think in response to this ticket. It changes libpact_ffi.version from 0.4.25 to 0.4.9, which goes backwards (maybe from taking "fixed in ≥ 0.4.9" literally?). 0.4.25 already has the fix and is 16 releases newer. It only touches the version file and nothing has been rebuilt from it yet, so no harm done so far. Worth noting the version file alone doesn't change anything until the XCFramework is rebuilt, which is the same trap that caused this bug.
3. Add a check for version drift: make sure the built binary's pactffi_version() matches libpact_ffi.version. Right now nothing notices when the version file is bumped but the binary isn't rebuilt, and that's what really caused this bug.

Optional, separate from the above:

4. Update to pact_ffi 0.5.4 (the latest). The wrapper uses 32 pactffi_* functions, and they all still exist in 0.5.4 except pactffi_verify. So Verifier.verifyProvider(options:) would need to move to the newer pactffi_verifier_* API. Both APIs exist in 0.4.x, so that change can be done and tested first, before bumping the version. Probably better as two separate PRs.

Happy to do any of these, just let me know which.

Evidence, if useful

The binary is 0.4.0. It has pact_models 1.0.4 and the version string 0.4.0 (0.4.7 shipped with pact_models 1.1.x). Skipping the matching rule is the buggy branch from the report, and it's still there:

$ BIN=.build/checkouts/PactSwiftMockServer/PactSwiftMockServer.xcframework/\
macos-arm64_x86_64/PactSwiftMockServer.framework/Versions/Current/PactSwiftMockServer

$ strings -a "$BIN" | grep -oE '/pact_models-[0-9.]+/|.{6}ffi0\.[0-9.]+' | sort -u
/pact_models-1.0.4/
handles.rsffi0.4.0

$ strings -a "$BIN" | grep -c 'Skipping the matching rule'
2

The version file was bumped, but the binary was never rebuilt:

$ git log --date=short --format='%h %ad %s' -- libpact_ffi.version | head -2
e72ef02 2024-04-20 Update rust reference module to 0.4.17
02ab36c 2023-01-12 tech: Update pact ffi to v0.4.0

$ git log --date=short --format='%h %ad %s' -- PactSwiftMockServer.xcframework | head -1
1d953dd 2023-01-13 chore: Update xcframework

v1.1.1 has the fix. It has pact_mock_server-1.2.11, the version string 0.4.25, and Skipping the matching rule gives 0 hits, so the buggy branch is gone. (0.4.9 rewrote process_matcher to build the example from variants directly, so it no longer needs a "value" key.)

[surpher]

PactSwiftMockServer needs to catch up with latest pactffi_ version and released regardless. Then PactSwift needs to rely on the new PactSwiftMockServer.

The decision to pin to a specific version is deliberate so that any upstream changes wouldn't break PactSwift and/or PactSwiftMockServer.

Rather easy job, I'm just busy with other things.

[surpher]

@pepejeria @mkieselmannPDG I updated the support shell scripts to set up the environment. Dropped support for x86_64 which should in turn also drop the size of PactSwiftMockServerXCFramework by ~30% (just guessing here - used to need 5 binaries, now only 3).

Feel free to grab the changes and attempt to fix the dropped pactffi_verify interface.

I will also add a CONTRIBUTING.md file describing what the process of setting up, building, testing and releasing it.