Hi <#CLS16AVEE|> / <#C9UTHV2AD|>, We are using Pac...
# pactflow
j
Hi #CLS16AVEE / #C9UTHV2AD, We are using Pactflow subscription for our contract testing. We noticed that the Datetime field verification for our bi-directional tests are failing for past couple of days (only for unspecified time format). But these tests are working for a while and we didn't face any failures. When we update the consumer tests to use LocalTime format or UTC time format, the tests are seems to be passing. So could you please tell if there are any recent updates in Pactflow which could be causing this issue? Attaching the provider and consumer contracts for your verification.
m
We definitely haven’t changed anything recently on this front.
I don’t think what you have provide is a valid ISO 8601 date. You could use
0001-01-01T00:00:00Z
or
0001-01-01T00:00:00+00:00
j
Thank you for the quick response. But we are wondering, how does the verification was successful for past 1 month and it started failing now. The verification is successful for - https://avevasoftwarellc.pactflow.io/contracts/bi-directional/provider/platform-instance-mg[…]8b74c6633887534426/cross-contract-verification-results
The only difference is that provider added a new endpoint in the swagger and there are no changes to the models. So I believe a change in the provider contract may have retriggered verification in Pactflow and causing this failure.
Also, I was under the impression that ISO 8601 allows 3 ways for specifying date time formats as per MS documentation - https://learn.microsoft.com/en-us/dotnet/standard/base-types/standard-date-and-time-format-strings#the-round-trip-o-o-format-specifier
m
You’re right, actually. It should be covered by the
time-secfrac
definition in the ABNF here: https://datatracker.ietf.org/doc/html/rfc3339#section-5.6
I’m not sure why it changed, but could you please raise an issue
(howtosupport)
s
Please create a ticket here with the issue details so that we can properly track the resolution and the PactFlow product support team will continue to work through it with you: https://support.smartbear.com/pactflow/message
m
Actually no, I was right the first time around - you still need to supply the TZ i.e.
0001-01-01T00:00:00.0000000Z
is valid but
0001-01-01T00:00:00.0000000
is not.
See also https://github.com/ajv-validator/ajv-formats/issues/70 (bug report to fix the previously working failure)
Oh, and I believe it would have started failing because we updated the validation library: https://github.com/pactflow/swagger-mock-validator/compare/14.2.0...14.4.0#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R73. This was a few weeks ago, which is why I initially thought it unrelated
j
Thank you @Matt (pactflow.io / pact-js / pact-go)
But somehow the new Pactflow UI is still showing 14.1.0 for the validator version.
m
That just means that was the version at the time it was verified
Is that the same error or a different one?
j
It is for the same failure. Probably I think, the validator is updated, but UI seems to be not reflecting correct version.
g
Hello, I'm seeing the same issue here. A bidirectional datetime validation started failing after a recent release. I've tested manually, and it broke between swagger-mock-validation 14.1.0 and 14.2.0 So, I suppose the issue would be here?
m
Yeah, I think so. It’s not a valid date time according to the RFC:
so the bug in our code was fixed, but this caused your tests to fail (exposing a bug in your code)
g
That's actually what I expected. Thanks for confirming it.
m
no probs!