starred/WireMock.Net-wiremock
1
0
Fork 0
mirror of https://github.com/wiremock/WireMock.Net.git synced 2026-07-27 15:28:36 +02:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

WireMock.Org nullable properties and defaults #615

New Issue
Closed
opened 2025-12-29 15:28:20 +01:00 by adam · 4 comments
adam commented 2025-12-29 15:28:20 +01:00
Owner
Copy Link
Copy Source

Originally created by @crate-scarter on GitHub (Jul 19, 2024).

Originally assigned to: @StefH on GitHub.

Describe the bug

It appears that when using the WireMock.Org.Abstractions to build a request to send to a wiremock/wiremock container, certain fields are present in the Abstractions that aren't required by the API itself. The main example that I saw was the presence of the fromConfiguredStub property on the response when creating a stub. This is a boolean flag that is used to indicate if its the "default, unmatched response, not present otherwise." That field is not required, and so therefore instead of passing the default of the boolean, it probably should be nullable where any null field is simply not sent in the API payload.

Expected behavior:

For fields that are not required to be sent to the API, the fields should probably be nullable in the abstractions to allow for not sending them in the request, which would preserve the default behavior when calling the Wiremock.Org API directly.

public class MappingsResponse {
 // removed properties
 [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
 public bool? FromConfiguredStub {get;set;}
}

This will cause the response sent to the API to not include that field

Test to reproduce

Create a Mapping by setting the WireMock.Org.Abstractions.MappingsRequest and WireMock.Org.Abstractions.MappingsResponse objects.

var request = new Request() {
 Url = "/test",
 Method = "GET"
};

var response = new Response() {
  Status = 200,
  Body = "Test"
  // FromConfiguredStub isn't set here, so it defaults to false
};


var mapping = new  WireMock.Org.Abstractions.Mapping() { Request = request, Response = response};
_httpClient.PostAsJsonAsync("__admin/mappings", mapping);

//make real request to the /test endpoint here will result in a 404

Other related info

I'm using the wiremock/wiremock:3.8.0 container

Originally created by @crate-scarter on GitHub (Jul 19, 2024). Originally assigned to: @StefH on GitHub. ### Describe the bug It appears that when using the WireMock.Org.Abstractions to build a request to send to a wiremock/wiremock container, certain fields are present in the Abstractions that aren't required by the API itself. The main example that I saw was the presence of the fromConfiguredStub property on the response when creating a stub. This is a boolean flag that is used to indicate if its the "default, unmatched response, not present otherwise." That field is not required, and so therefore instead of passing the default of the boolean, it probably should be nullable where any null field is simply not sent in the API payload. ### Expected behavior: For fields that are not required to be sent to the API, the fields should probably be nullable in the abstractions to allow for not sending them in the request, which would preserve the default behavior when calling the Wiremock.Org API directly. ``` public class MappingsResponse { // removed properties [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)] public bool? FromConfiguredStub {get;set;} } ``` This will cause the response sent to the API to not include that field ### Test to reproduce Create a Mapping by setting the WireMock.Org.Abstractions.MappingsRequest and WireMock.Org.Abstractions.MappingsResponse objects. ``` var request = new Request() { Url = "/test", Method = "GET" }; var response = new Response() { Status = 200, Body = "Test" // FromConfiguredStub isn't set here, so it defaults to false }; var mapping = new WireMock.Org.Abstractions.Mapping() { Request = request, Response = response}; _httpClient.PostAsJsonAsync("__admin/mappings", mapping); //make real request to the /test endpoint here will result in a 404 ``` ### Other related info I'm using the `wiremock/wiremock:3.8.0` container
adam added the bug label 2025-12-29 15:28:20 +01:00
adam closed this issue 2025-12-29 15:28:20 +01:00
adam commented 2025-12-29 15:28:21 +01:00
Author
Owner
Copy Link
Copy Source

@StefH commented on GitHub (Jul 20, 2024):

I can change that field to public bool? FromConfiguredStub { get; set; }.

But it this the only field?

@StefH commented on GitHub (Jul 20, 2024): I can change that field to `public bool? FromConfiguredStub { get; set; }`. But it this the only field?
adam commented 2025-12-29 15:28:21 +01:00
Author
Owner
Copy Link
Copy Source

@crate-scarter commented on GitHub (Jul 22, 2024):

It's hard to say for all of the APIs. I was going through just the insert new stub API method. I think any primitive type other than string would potentially run into this same scenario, though for the other ones like fixedDelayMilliseconds defaults to 0 so it ends up being the behavior that would be expected anyway. In this particular usage, it looks like the only fields that are not objects or strings are priority, persistent, fixedDelayMilliseconds, and fromConfiguredStub. I think only the last one is likely to need the change.

@crate-scarter commented on GitHub (Jul 22, 2024): It's hard to say for all of the APIs. I was going through just the insert new stub API method. I think any primitive type other than string would potentially run into this same scenario, though for the other ones like fixedDelayMilliseconds defaults to 0 so it ends up being the behavior that would be expected anyway. In this particular usage, it looks like the only fields that are not objects or strings are priority, persistent, fixedDelayMilliseconds, and fromConfiguredStub. I think only the last one is likely to need the change.
adam commented 2025-12-29 15:28:21 +01:00
Author
Owner
Copy Link
Copy Source

@StefH commented on GitHub (Jul 22, 2024):

For now I will just fix the FromConfiguredStub.

@StefH commented on GitHub (Jul 22, 2024): For now I will just fix the FromConfiguredStub.
adam commented 2025-12-29 15:28:21 +01:00
Author
Owner
Copy Link
Copy Source

@StefH commented on GitHub (Jul 22, 2024):

https://github.com/WireMock-Net/WireMock.Net/pull/1142

@StefH commented on GitHub (Jul 22, 2024): https://github.com/WireMock-Net/WireMock.Net/pull/1142
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 labels bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#615