> The example values should represent what the...
# libpact_ffi-userst
Tien Vo
10/26/2023, 3:45 AMThe example values should represent what the matcher is matching. In the customer facing DSL, this should be validated.
Tien Vo
10/26/2023, 3:46 AMIf I understand correctly, this suggestion is quite opposite with this suggestion from Matt https://pact-foundation.slack.com/archives/C9VBGLUM9/p1690516277135829?thread_ts=1690472580.471449&cid=C9VBGLUM9
r
rholshausen
10/26/2023, 4:41 AMYes, because the DSL layer (what is exposed to the user) has the context on what is trying to be done. The backend Rust API does not have that context, so how can it know whether one matcher is not the correct one to use with another generator.
rholshausen
10/26/2023, 4:44 AMIf you have a DSL function
integer(100)\d+t
Tien Vo
10/31/2023, 6:20 AMBecause of regex validation, I can't register the
interaction #1The pattern \w{3}\d{3} is not valid for value a. Failed with error code 0. (PhpPact\Consumer\Matcher\Exception\InvalidRegexException)
Tien Vo
11/03/2023, 2:18 AMI think the simple solution is to provide a way to disable regex validation during running compatibility suite
r
rholshausen
11/03/2023, 2:42 AMIs it just the example value that is not correct? Can we fix that in the suite, or is it a PHP issue?
rholshausen
11/03/2023, 2:45 AMIf we change the regex to
\\w{1,3}\\d{0,3}t
Tien Vo
11/03/2023, 2:52 AMThe problem is: I think compatibility suite is built with pact-rust in mind. This is one example. In pact-rust, we can simply set the regex matcher, no need to validate the value with it.
In pact-php (and probably in other languages), we need to validate the value first before setting the regex matcher.
I don't think updating
compatibility suitepact-php