starred/WireMock.Net-wiremock
1
0
Fork 0
mirror of https://github.com/wiremock/WireMock.Net.git synced 2026-01-11 22:30:41 +01:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

JsonMatcher not working when JSON contains a DateTimeOffset #218

New Issue
Closed
opened 2025-12-29 14:25:27 +01:00 by adam · 12 comments
adam commented 2025-12-29 14:25:27 +01:00
Owner
Copy Link

Originally created by @JoshKeegan on GitHub (Oct 8, 2019).

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

Originally created by @JoshKeegan on GitHub (Oct 8, 2019). 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: ``` js { 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: ``` js { "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: ``` js { 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
adam added the bug label 2025-12-29 14:25:27 +01:00
adam closed this issue 2025-12-29 14:25:27 +01:00
adam commented 2025-12-29 14:25:30 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Oct 8, 2019):

This looks a lot like https://github.com/WireMock-Net/WireMock.Net/issues/347

I'll investigate the JsonMatcher code...

@StefH commented on GitHub (Oct 8, 2019): This looks a lot like https://github.com/WireMock-Net/WireMock.Net/issues/347 I'll investigate the JsonMatcher code...
adam commented 2025-12-29 14:25:31 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Oct 8, 2019):

#358

@StefH commented on GitHub (Oct 8, 2019): #358
adam commented 2025-12-29 14:25:31 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Oct 8, 2019):

@JoshKeegan
Can you please try preview version on MyGet?

WireMock.Net.1.0.32-ci-11968.nupkg

@StefH commented on GitHub (Oct 8, 2019): @JoshKeegan Can you please try preview version on MyGet? `WireMock.Net.1.0.32-ci-11968.nupkg`
adam commented 2025-12-29 14:25:32 +01:00
Author
Owner
Copy Link

@JoshKeegan commented on GitHub (Oct 8, 2019):

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.

@JoshKeegan commented on GitHub (Oct 8, 2019): 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.
adam commented 2025-12-29 14:25:32 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Oct 9, 2019):

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

@StefH commented on GitHub (Oct 9, 2019): 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
adam commented 2025-12-29 14:25:32 +01:00
Author
Owner
Copy Link

@JoshKeegan commented on GitHub (Oct 9, 2019):

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 👍

@JoshKeegan commented on GitHub (Oct 9, 2019): 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 👍
adam commented 2025-12-29 14:25:32 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Oct 9, 2019):

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.

@StefH commented on GitHub (Oct 9, 2019): 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.
adam commented 2025-12-29 14:25:33 +01:00
Author
Owner
Copy Link

@JoshKeegan commented on GitHub (Oct 9, 2019):

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.

@JoshKeegan commented on GitHub (Oct 9, 2019): 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.
adam commented 2025-12-29 14:25:33 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Oct 9, 2019):

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

@StefH commented on GitHub (Oct 9, 2019): Building docker Linux takes ~3 minutes. Building docker Windows takes ~7 minutes.
adam commented 2025-12-29 14:25:33 +01:00
Author
Owner
Copy Link

@JoshKeegan commented on GitHub (Oct 9, 2019):

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 commented on GitHub (Oct 9, 2019): 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.
adam commented 2025-12-29 14:25:33 +01:00
Author
Owner
Copy Link

@JoshKeegan commented on GitHub (Oct 9, 2019):

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 :)

@JoshKeegan commented on GitHub (Oct 9, 2019): 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 :)
adam commented 2025-12-29 14:25:34 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Oct 9, 2019):

"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.

@StefH commented on GitHub (Oct 9, 2019): "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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
bug
doc
doc
duplicate
feature
feature
invalid
pull-request
Mirrored from GitHub Pull Request
 question
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#218
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?