JsonMatcher not working when JSON contains a DateTimeOffset

[JoshKeegan]

Hi,
I'm trying to match wiremock match on the body of an incoming POST, and am having trouble with DateTimeOffsets.

If we start with the example from the wiki: https://github.com/WireMock-Net/WireMock.Net/wiki/Request-Matching#json-jsonmatcher
everything works as expected. A request to /jsonmatcher1 with the body:

{
	x: 42,
	s: "s"
}

works as expected and gives the response.

When I delete that mapping and add a new one with a DateTimeOffset property in the body:

{
    "Guid": "debaf408-3b23-4c04-9d18-ef1c020e79f2",
    "Request": {
        "Path": {
            "Matchers": [
                {
                    "Name": "WildcardMatcher",
                    "Pattern": "/jsonmatcher1"
                }
            ]
        },
        "Methods": [
            "post"
        ],
        "Body": {
            "Matcher": {
                "Name": "JsonMatcher",
                "Pattern": "{ \"x\": 42, \"s\": \"s\", \"preferredAt\": \"2019-11-21T10:32:53.2210009+00:00\" }"
            }
        }
    },
    "Response": {
        "StatusCode": 200,
        "Body": "{ \"result\": \"jsonbodytest\" }",
        "UseTransformer": false
    }
}

and send the same request as before, but now with body:

{
	x: 42,
	s: "s",
	preferredAt: "2019-11-21T10:32:53.2210009+00:00"
}

it doesn't work (returns {"Status": "No matching mapping found"}).

I assume wiremock.net is doing some special processing on these DateTimeOffset values and it isn't working in this case, or am I doing something wrong?
Also: Is there any way of making wiremock.net treat these as strings and just compare them as strings? For my current use-case that would suffice.
Cheers,
Josh

[StefH]

This looks a lot like #347

I'll investigate the JsonMatcher code...

[StefH]

#358

[StefH]

@JoshKeegan
Can you please try preview version on MyGet?

WireMock.Net.1.0.32-ci-11968.nupkg

[JoshKeegan]

Will take a look, thanks!
I don’t suppose you have it available as a docker image? That’s how I’m using it currently.

[StefH]

I don't have any automatic previews for docker available.
Maybe I could just merge the code to master, or add some more tests.

Can you maybe also take a look at the PR -> #358

[JoshKeegan]

Alright, no problem, I'll try and use the nuget package or create a docker image myself.
For me, auto-publishing docker images would be really useful to have (just publish to the container registry tagged with the build ID and not tagged as latest unless it's on master).
We're using wiremock within docker and kubernetes, so having access to feature/bug fix builds like this in docker would be really useful.

RE the PR: looks good & looks like it will solve this problem! Have left one comment, but it's probably more about my lack of understanding of how it works 👍

[StefH]

Currently I've two builds : a build to build WireMock code and do tests and publish to MyGet.

And I've a separate build to only create (latest + versioned) docker images and publish these.

So I've to modify the the first build, however I dont want to buidl a docker always, takes too much time... I've to think on that.

[JoshKeegan]

Fair enough, I didn't expect it to take very long to make the image.
Perhaps I'll take a look at a build & see what's time consuming, maybe we could make it faster.

[StefH]

Building docker Linux takes ~3 minutes.
Building docker Windows takes ~7 minutes.

[JoshKeegan]

Taken a quick look at the build code for the linux container (I can't see the actual pipeline linked anywhere?) & I'd imagine the biggest slow down will be pulling the nuget packages. As it's running on a hosted agent there isn't a whole lot we could do about this though :(

Only thing of note is that it looks like the code might be being built twice. It's using a multi-stage dockerfile and the first image handles the build (via dotnet publish, but it isn't specifying --no-build) I think that will do the build again. That's fine and probably what you want (so you're in full control of the version of .net used to do the build), but that means you can delete the "Build StandAlone.NETCoreApp" task from the pipline yaml.

Can't imagine that will save much time, but it's better than nothing. I'd be interested to see a build log to see what actually takes the time though.

[JoshKeegan]

I can confirm that your fix has worked for me!
I've run the standalone app locally after upgrading to the CI nuget packages & everything works for me.
Let me know when the docker image is released :)

[StefH]

"Build StandAlone.NETCoreApp" is probably there to quickly check if the code can build.

Cool that it works, I will close this issue and a new official NuGet + docker will be released in few days. Just keep watching this project or dockerhub.