Loading mapping models with JsonMatcher is not working correctly #294

New Issue

Closed

opened 2025-12-29 15:19:53 +01:00 by adam · 19 comments

adam commented 2025-12-29 15:19:53 +01:00

Owner

Copy Link

Originally created by @cezarypiatekGC on GitHub (Sep 17, 2020).

Describe the bug

Loading mapping models with JsonMatcher for Body matcher from a file is not working correctly.

Steps to reproduce:

1. Create mapping with JsonMatcher for the body and save it to file as follow

var requestBuilder = Request.Create()
	.WithPath("/api/v1.0/accounts/")
	.WithHeader("Content-Type", "application/json; charset=utf-8")
	.WithBody(new JsonMatcher(new { AccountIds = new[] { 1, 2, 3} }))
	.UsingPost();

var respondWithAProvider = wiremockServer.Given(requestBuilder, saveToFile: true);

var responseProvider = Response.Create()
	.WithStatusCode(200)
	.WithHeader("Content-Type", "application/json; charset=utf-8")
	.WithBody(JsonConvert.SerializeObject(new[] { 1, 2, 3 }));

wiremockServer.RespondWith(responseProvider);

2. As a result I get a file with the following content

{
  "Guid": "7d1c7dcc-eba1-4c3a-bc82-0a444fe9fcd9",
  "Request": {
    "Path": {
      "Matchers": [
        {
          "Name": "WildcardMatcher",
          "Pattern": "/api/v1.0/accounts/",
          "IgnoreCase": false
        }
      ]
    },
    "Methods": [
      "POST"
    ],
    "Headers": [
      {
        "Name": "Content-Type",
        "Matchers": [
          {
            "Name": "WildcardMatcher",
            "Pattern": "application/json; charset=utf-8",
            "IgnoreCase": true
          }
        ]
      }
    ],
    "Body": {
      "Matcher": {
        "Name": "JsonMatcher",
        "Pattern": {
          "AccountIds": [1, 2, 3]
        },
        "IgnoreCase": false
      }
    }
  },
  "Response": {
    "StatusCode": 200,
    "BodyDestination": "SameAsSource",
    "Body": "[1,2,3]",
    "Headers": {
      "Content-Type": "application/json; charset=utf-8"
    }
  }
}

3. Load mapping from file and feed it to the WireMock server

var content = File.ReadAllText(@"__admin\mappings\7d1c7dcc-eba1-4c3a-bc82-0a444fe9fcd9.json");
wiremockServer.WithMapping(content);

Expected behavior:

This is how requestBuilder looks like before saving mapping to a file

This is how requestBuilder looks like after loading from a file

The expectation is that the JsonMatcher works in the same way when loaded from a file and when created from the code. Currently, the pattern is always set to null when loading from a file.

Other notes

This is probably caused by this line where every pattern is cast to string (non-string values will result with a null)
7abf56eafa/src/WireMock.Net/Serialization/MatcherMapper.cs (L39)

Originally created by @cezarypiatekGC on GitHub (Sep 17, 2020). ### Describe the bug Loading mapping models with `JsonMatcher` for Body matcher from a file is not working correctly. ### Steps to reproduce: 1. Create mapping with JsonMatcher for the body and save it to file as follow ```cs var requestBuilder = Request.Create() .WithPath("/api/v1.0/accounts/") .WithHeader("Content-Type", "application/json; charset=utf-8") .WithBody(new JsonMatcher(new { AccountIds = new[] { 1, 2, 3} })) .UsingPost(); var respondWithAProvider = wiremockServer.Given(requestBuilder, saveToFile: true); var responseProvider = Response.Create() .WithStatusCode(200) .WithHeader("Content-Type", "application/json; charset=utf-8") .WithBody(JsonConvert.SerializeObject(new[] { 1, 2, 3 })); wiremockServer.RespondWith(responseProvider); ``` 2. As a result I get a file with the following content ```json { "Guid": "7d1c7dcc-eba1-4c3a-bc82-0a444fe9fcd9", "Request": { "Path": { "Matchers": [ { "Name": "WildcardMatcher", "Pattern": "/api/v1.0/accounts/", "IgnoreCase": false } ] }, "Methods": [ "POST" ], "Headers": [ { "Name": "Content-Type", "Matchers": [ { "Name": "WildcardMatcher", "Pattern": "application/json; charset=utf-8", "IgnoreCase": true } ] } ], "Body": { "Matcher": { "Name": "JsonMatcher", "Pattern": { "AccountIds": [1, 2, 3] }, "IgnoreCase": false } } }, "Response": { "StatusCode": 200, "BodyDestination": "SameAsSource", "Body": "[1,2,3]", "Headers": { "Content-Type": "application/json; charset=utf-8" } } } ``` 3. Load mapping from file and feed it to the WireMock server ```cs var content = File.ReadAllText(@"__admin\mappings\7d1c7dcc-eba1-4c3a-bc82-0a444fe9fcd9.json"); wiremockServer.WithMapping(content); ``` ### Expected behavior: This is how `requestBuilder` looks like before saving mapping to a file  This is how `requestBuilder` looks like after loading from a file  The expectation is that the JsonMatcher works in the same way when loaded from a file and when created from the code. Currently, the pattern is always set to null when loading from a file. ### Other notes This is probably caused by this line where every pattern is cast to string (non-string values will result with a `null`) https://github.com/WireMock-Net/WireMock.Net/blob/7abf56eafaf9d57aff1234bf7c0ad0f408bb18d6/src/WireMock.Net/Serialization/MatcherMapper.cs#L39

adam added the bug label 2025-12-29 15:19:53 +01:00

adam closed this issue 2025-12-29 15:19:53 +01:00

adam commented 2025-12-29 15:19:54 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Sep 19, 2020):

Hello @cezarypiatekGC . Thank you for your research.

@StefH commented on GitHub (Sep 19, 2020): Hello @cezarypiatekGC . Thank you for your research.

adam commented 2025-12-29 15:19:54 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Sep 19, 2020):

#505

@cezarypiatekGC : can you try preview version from MyGet : WireMock.Net.1.2.18-ci-13750.nupkg ?

@StefH commented on GitHub (Sep 19, 2020): #505 @cezarypiatekGC : can you try preview version from MyGet : `WireMock.Net.1.2.18-ci-13750.nupkg` ?

adam commented 2025-12-29 15:19:55 +01:00

Author

Owner

Copy Link

@cezarypiatekGC commented on GitHub (Sep 19, 2020):

I've tested this preview package and there's still a difference between JsonMatcher before saving to file and after loading which affects how the matcher works.

Before saving to file

After loading from a file

JObject vs JArray

@cezarypiatekGC commented on GitHub (Sep 19, 2020): I've tested this preview package and there's still a difference between JsonMatcher before saving to file and after loading which affects how the matcher works. Before saving to file  After loading from a file  JObject vs JArray

adam commented 2025-12-29 15:19:55 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Sep 19, 2020):

Can you try new version WireMock.Net.1.2.18-ci-13754.nupkg (or higher)?

@StefH commented on GitHub (Sep 19, 2020): Can you try new version `WireMock.Net.1.2.18-ci-13754.nupkg` (or higher)?

adam commented 2025-12-29 15:19:55 +01:00

Author

Owner

Copy Link

@cezarypiatekGC commented on GitHub (Sep 19, 2020):

I've tried with WireMock.Net.1.2.18-ci-13754 but still, JsonMatcher has a different value and It's not working in the same way as it worked before saving to a file.

@cezarypiatekGC commented on GitHub (Sep 19, 2020): I've tried with WireMock.Net.1.2.18-ci-13754 but still, JsonMatcher has a different value and It's not working in the same way as it worked before saving to a file.  

adam commented 2025-12-29 15:19:56 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Sep 20, 2020):

Note that the Value property will not be the same, because in your initial code this is an anonymous object. And when the mapping is read from a .json file, this is a JObject. But the _valueAsJToken is used for matching, and this should be the same.

So can you make a full example (unit test) which demonstrates your issue?

@StefH commented on GitHub (Sep 20, 2020): Note that the `Value` property will not be the same, because in your initial code this is an anonymous object. And when the mapping is read from a .json file, this is a JObject. But the `_valueAsJToken` is used for matching, and this should be the same. So can you make a full example (unit test) which demonstrates your issue?

adam commented 2025-12-29 15:19:56 +01:00

Author

Owner

Copy Link

@cezarypiatekGC commented on GitHub (Sep 21, 2020):

Ok, I will try to prepare a test or demo app that reproduces that problem.

@cezarypiatekGC commented on GitHub (Sep 21, 2020): Ok, I will try to prepare a test or demo app that reproduces that problem.

adam commented 2025-12-29 15:19:56 +01:00

Author

Owner

Copy Link

@RiccoFerraro commented on GitHub (Sep 29, 2020):

Hi guys, I also believe I'm having this problem. I have static mappings (generated via recording with wiremock.net) I just upgraded to 1.3.0. I've debugged into JsonMatcher and it appears _valueAsJToken is always a jtoken for a null object, This is even when there is a request body and specified JsonMatcher. The result, is that no matter what I supply in the payload, matching doesn't appear to happen in any way on the request body.

Not sure what I'm doing wrong here, but I feel like I've tried a million different things. Here is the mapping json for a particular request body:
.

UPDATE:
On Further inspection it seems to have to do with converting the Patterns into an array? The Patterns object looks just fine, but the stringPattern is null.

@RiccoFerraro commented on GitHub (Sep 29, 2020): Hi guys, I also believe I'm having this problem. I have static mappings (generated via recording with wiremock.net) I just upgraded to 1.3.0. I've debugged into JsonMatcher and it appears `_valueAsJToken` is always a jtoken for a null object, This is even when there is a request body and specified `JsonMatcher`. The result, is that no matter what I supply in the payload, matching doesn't appear to happen in any way on the request body.  Not sure what I'm doing wrong here, but I feel like I've tried a million different things. Here is the mapping json for a particular request body: .  UPDATE: On Further inspection it seems to have to do with converting the `Patterns` into an array? The `Patterns` object looks just fine, but the stringPattern is null. 

adam commented 2025-12-29 15:19:57 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Sep 30, 2020):

Hello @RiccoFerraro,

The 1.3.0 version does not have any preview fixed code for this issue, in order to test that you need MyGet version WireMock.Net.1.2.18-ci-13754.nupkg.
Or if you want to debug, you can use the PR : https://github.com/WireMock-Net/WireMock.Net/pull/505

And can you create a full working example please?

@StefH commented on GitHub (Sep 30, 2020): Hello @RiccoFerraro, The 1.3.0 version does not have any preview fixed code for this issue, in order to test that you need MyGet version `WireMock.Net.1.2.18-ci-13754.nupkg`. Or if you want to debug, you can use the PR : https://github.com/WireMock-Net/WireMock.Net/pull/505 And can you create a full working example please?

adam commented 2025-12-29 15:19:57 +01:00

Author

Owner

Copy Link

@RiccoFerraro commented on GitHub (Sep 30, 2020):

Hi @StefH Will do. I'll get back to you on if the issue is in that alpha build

@RiccoFerraro commented on GitHub (Sep 30, 2020): Hi @StefH Will do. I'll get back to you on if the issue is in that alpha build

adam commented 2025-12-29 15:19:57 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Oct 7, 2020):

Hello @RiccoFerraro,did you have time yet to verify ?

@StefH commented on GitHub (Oct 7, 2020): Hello @RiccoFerraro,did you have time yet to verify ?

adam commented 2025-12-29 15:19:58 +01:00

Author

Owner

Copy Link

@RiccoFerraro commented on GitHub (Oct 7, 2020):

@StefH Sorry I haven't had a chance yet. I will try to take a look at this sometime this week. I'll post here when I've tried it.

@RiccoFerraro commented on GitHub (Oct 7, 2020): @StefH Sorry I haven't had a chance yet. I will try to take a look at this sometime this week. I'll post here when I've tried it.

adam commented 2025-12-29 15:19:58 +01:00

Author

Owner

Copy Link

@RiccoFerraro commented on GitHub (Oct 12, 2020):

@StefH Sorry for the delay, still haven't had a chance to test this fix out yet. I've been absolutely slammed with work and will get to it as soon as I get a second.

On a related note, I did notice something else about partial match scores that seemed off. (probably requires a little redesign). For our team to continue using wiremock.net we need to trust that the Http VERB is ALWAYS respected. I've been noticing that, even when a post call is fired, Get matches are being favored (given higher scores) over POST calls (in this case because of the bug mentioned above, the POST call has a lower score because it is failing to match on the body matcher). This seems off. It should match on the highest score, for only a single verb type. I can't imagine a scenario where someone is okay with a get request/response being returned for a post call in an integration test??? That would be a broken integration test to me. Can we introduce a flag to strictly enforce just the verb?

@RiccoFerraro commented on GitHub (Oct 12, 2020): @StefH Sorry for the delay, still haven't had a chance to test this fix out yet. I've been absolutely slammed with work and will get to it as soon as I get a second. On a related note, I did notice something else about partial match scores that seemed off. (probably requires a little redesign). For our team to continue using wiremock.net we need to trust that the Http VERB is ALWAYS respected. I've been noticing that, even when a post call is fired, Get matches are being favored (given higher scores) over POST calls (in this case because of the bug mentioned above, the POST call has a lower score because it is failing to match on the body matcher). This seems off. It should match on the highest score, for only a single verb type. I can't imagine a scenario where someone is okay with a get request/response being returned for a post call in an integration test??? That would be a broken integration test to me. Can we introduce a flag to strictly enforce just the verb?

adam commented 2025-12-29 15:19:58 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Oct 12, 2020):

@RiccoFerraro Thanks about your remark about the Http VERB. I did create a new Issue for this, and I'll take a look how to fix this.

@StefH commented on GitHub (Oct 12, 2020): @RiccoFerraro Thanks about your remark about the Http VERB. I did create a new Issue for this, and I'll take a look how to fix this.

adam commented 2025-12-29 15:20:00 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Oct 14, 2020):

@RiccoFerraro Investigating + solving that Http Method issue will take some more time.

Are you able to verify this issue ?
Else I will just create a new version because some code is also verified by https://github.com/WireMock-Net/WireMock.Net/issues/513

@StefH commented on GitHub (Oct 14, 2020): @RiccoFerraro Investigating + solving that Http Method issue will take some more time. Are you able to verify this issue ? Else I will just create a new version because some code is also verified by https://github.com/WireMock-Net/WireMock.Net/issues/513

adam commented 2025-12-29 15:20:00 +01:00

Author

Owner

Copy Link

@RiccoFerraro commented on GitHub (Oct 14, 2020):

Hi @StefH, thanks for being so responsive. I'm sorry I don't have time to create test projects and try the all the different versions this week. What I can do is pull down the version in https://github.com/WireMock-Net/WireMock.Net/issues/513 and see if the problems I was having with post body matching are fixed. After that seems to work, I'll work on setting "ParitalMapping" to false to enforce strict mapping. Question, is it in an official nuget.org version? I can't use my-get outside of POC's.

@RiccoFerraro commented on GitHub (Oct 14, 2020): Hi @StefH, thanks for being so responsive. I'm sorry I don't have time to create test projects and try the all the different versions this week. What I can do is pull down the version in https://github.com/WireMock-Net/WireMock.Net/issues/513 and see if the problems I was having with post body matching are fixed. After that seems to work, I'll work on setting "ParitalMapping" to false to enforce strict mapping. Question, is it in an official nuget.org version? I can't use my-get outside of POC's.

adam commented 2025-12-29 15:20:00 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Oct 14, 2020):

Hello @RiccoFerraro , I'll release a new version with this fix tonight and for now close this issue.

In case you have another problem please create a new issue.

@StefH commented on GitHub (Oct 14, 2020): Hello @RiccoFerraro , I'll release a new version with this fix tonight and for now close this issue. In case you have another problem please create a new issue.

adam commented 2025-12-29 15:20:01 +01:00

Author

Owner

Copy Link

@RiccoFerraro commented on GitHub (Dec 11, 2020):

Hi @StefH Great stuff on that fix! it appears to work as expected! Quick question, What is the expected behavior for record playback for repeated calls to the same endpoint with these settings in 1.3.7? What I'm apparently experiencing is wiremock doesn't seem to actually proxy the second call to the same endpoint, and instead is serving it's recorded response. This is a problem, because the expected behavior of the endpoint in question is that it changes between calls and i need to capture both responses. I have verified this by calling the endpoint directly in postman (with and without the wiremock server base url) and I get different response. Maybe this can be solved by reseting the server mid test?

@RiccoFerraro commented on GitHub (Dec 11, 2020): Hi @StefH Great stuff on that fix! it appears to work as expected! Quick question, What is the expected behavior for record playback for repeated calls to the same endpoint with these settings in 1.3.7? What I'm apparently experiencing is wiremock doesn't seem to actually proxy the second call to the same endpoint, and instead is serving it's recorded response. This is a problem, because the expected behavior of the endpoint in question is that it changes between calls and i need to capture both responses. I have verified this by calling the endpoint directly in postman (with and without the wiremock server base url) and I get different response. Maybe this can be solved by reseting the server mid test? 

adam commented 2025-12-29 15:20:01 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Dec 12, 2020):

@RiccoFerraro
Did you already try "SaveMapping" = false and "SaveMappingToFile" = true ?

@StefH commented on GitHub (Dec 12, 2020): @RiccoFerraro Did you already try "SaveMapping" = false and "SaveMappingToFile" = true ?

adam referenced this issue 2025-12-29 15:33:38 +01:00

[PR #294] [MERGED] don't strip request body if we don't recognize the request method #843

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

master

mime-part-matcher

version-2.x

MappingSerializer

1341-mapping-json

stef-aspire-tests-updates

bug/973-TinyMapper

bug/1149-AppendGuidToSavedMappingFile

feature/1150-DockerImageVersion

61

stef-1108

stef-1097

stef-1083-MessageOptions_Type_Conflict

stef-1062-logger

stef-IgnoreOpenApiErrors

stef-928-TypeLoadException-FluentAssertions-net472

nunit

stef-849

stef-847-regex-questionmark

http_verb

WireMockServerContext

webapp

ai

CommandLineArgumentsParser

1.23.0

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.0

1.15.0

1.14.0

1.13.0

1.12.0

1.11.2

1.11.0

1.10.1

1.10.0

1.9.1

1.9.0

1.8.18

1.8.17

1.8.16

1.8.15

1.8.14

1.8.13

1.8.12

1.8.11

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.3

1.8.2

1.8.1

1.8.0

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.12

1.6.11

1.6.10

1.6.9

1.6.8

1.6.7

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.62

1.5.61

1.5.60

1.5.59

1.5.58

1.5.57

1.5.56

1.5.55

1.5.54

1.5.53

1.5.52

1.5.51

1.5.50

1.5.49

1.5.48

1.5.47

1.5.46

1.5.45

1.5.44

1.5.43

1.5.42

1.5.41

1.5.40

1.5.39

1.5.38

1.5.37

1.5.36

1.5.35

1.5.34

1.5.33

1.5.32

1.5.31

1.5.30

1.5.29

1.5.28

1.5.27

1.5.26

1.5.25

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.43

1.4.42

1.4.41

1.4.40

1.4.39

1.4.38

1.4.37

1.4.36

1.4.35

1.4.34

1.4.33

1.4.32

1.4.31

1.4.30

1.4.29

1.4.28

1.4.27

1.4.26

1.4.25

1.4.24

1.4.23

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.10

1.3.9

1.3.8

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11.0

1.2.10

1.2.9.0

1.2.8.0

1.2.7.0

1.2.6.0

1.2.5.0

1.2.4.0

1.2.3.0

1.2.2.0

1.2.1.0

1.2.0.0

1.1.10

1.1.9.0

1.1.8.0

1.1.7.0

1.1.6.0

1.1.5.0

1.1.3.0

1.1.2.0

1.1.1.0

1.1.0.0

1.0.43.0

1.0.42.0

1.0.41.0

1.0.40.0

1.0.39.0

1.0.38.0

1.0.37.0

1.0.36.0

1.0.35.0

1.0.34.0

1.0.33.0

1.0.32.0

1.0.31.0

1.0.29.0

1.0.28.0

1.0.25.0

1.0.24.0

1.0.23.0

1.0.22.0

1.0.21.0

1.0.20.0

1.0.19.0

1.0.18.0

1.0.17.0

1.0.16.0

1.0.15.0

1.0.14.0

1.0.13.0

1.0.12.0

1.0.11.0

1.0.10.0

1.0.9.0

1.0.8.0

1.0.7.0

1.0.6.1

1.0.6

1.0.5

1.0.4.21

1.0.4.20

1.0.4.19

1.0.4.18

1.0.4.17

1.0.4.16

1.0.4.15

1.0.4.14

1.0.4.13

1.0.4.12

1.0.4.11

1.0.4.10

1.0.4.9

1.0.4.8

1.0.4.7

1.0.4.6

1.0.4.5

1.0.4.4

1.0.4.3

1.0.4.2

1.0.4.1

1.0.4.0

1.0.3.20

1.0.3.19

1.0.3.18

1.0.3.17

1.0.3.16

1.0.3.15

1.0.3.14

1.0.3.13

1.0.3.12

1.0.3.11

1.0.3.10

1.0.3.9

1.0.3.8

1.0.3.7

1.0.3.6

1.0.3.5

1.0.3.4

1.0.3.3

1.0.3.2

1.0.3.1

1.0.3.0

1.0.2.13

1.0.2.12

1.0.2.11

1.0.2.10

1.0.2.9

1.0.2.8

1.0.2.7

1.0.2.6

1.0.2.5

1.0.2.4

1.0.2.1

1.0.2.0

1.0.1.5

1.0.1.3

1.0.1.2

1.0.1.1

1.0.0.0

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

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#294