Mappings could have a remaining hit counter that upon reaching 0 would stop being considered #318

New Issue

Closed

opened 2025-12-29 08:26:00 +01:00 by adam · 4 comments

adam commented 2025-12-29 08:26:00 +01:00

Owner

Copy Link

Originally created by @edabreu on GitHub (Dec 2, 2020).

Is your feature request related to a problem? Please describe.
I've recently replaced the use of MockServer with WireMock.net. The main issue that I've found so far is not being able to setup stubs/expectations to have a counter to control its availability. Let's imagine the scenario where I want to simulate the recovery from a failure when calling an external service. Imagining that I have a Polly retry policy for http transient errors I would like to test a scenario where, for example, the first N attempts would return status 5XX, and after that I could have a successful one returning 200.

Describe the solution you'd like
In order for this to test I would like to be able to setup a stub that would respond with status 5XX for the first N calls with priority 1 and another stub that would respond with a payload and status 200 with priority 2. Both stubs would match the same request, but the first one would only match while the defined counter was greater than 0.

Describe alternatives you've considered
Taking into consideration the previously presented communication's recovery scenario I don't think that any of the existing alternatives (timeouts, random timeouts, mixed priorities) would allow this to be tested because once a stub is created it will be there until a reset is made.

Is your feature request supported by WireMock (java version)? Please provide details.
It is my understanding that the java version also doesn't support this.

Originally created by @edabreu on GitHub (Dec 2, 2020). **Is your feature request related to a problem? Please describe.** I've recently replaced the use of MockServer with WireMock.net. The main issue that I've found so far is not being able to setup stubs/expectations to have a counter to control its availability. Let's imagine the scenario where I want to simulate the recovery from a failure when calling an external service. Imagining that I have a Polly retry policy for http transient errors I would like to test a scenario where, for example, the first N attempts would return status 5XX, and after that I could have a successful one returning 200. **Describe the solution you'd like** In order for this to test I would like to be able to setup a stub that would respond with status 5XX for the first N calls with priority 1 and another stub that would respond with a payload and status 200 with priority 2. Both stubs would match the same request, but the first one would only match while the defined counter was greater than 0. **Describe alternatives you've considered** Taking into consideration the previously presented communication's recovery scenario I don't think that any of the existing alternatives (timeouts, random timeouts, mixed priorities) would allow this to be tested because once a stub is created it will be there until a reset is made. **Is your feature request supported by [WireMock (java version)](https://www.wiremock.org)? Please provide details.** It is my understanding that the java version also doesn't support this.

adam added the question label 2025-12-29 08:26:00 +01:00

adam closed this issue 2025-12-29 08:26:00 +01:00

adam commented 2025-12-29 08:26:01 +01:00

Author

Owner

Copy Link

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

Hello @edabreu,

I think your question can be solved by using https://github.com/WireMock-Net/WireMock.Net/wiki/Scenarios-and-States

Particularly, in your case, "https://github.com/WireMock-Net/WireMock.Net/wiki/Scenarios-and-States#stay-in-the-same-state-for-a-number-of-requests" would be solution.

@StefH commented on GitHub (Dec 2, 2020): Hello @edabreu, I think your question can be solved by using https://github.com/WireMock-Net/WireMock.Net/wiki/Scenarios-and-States Particularly, in your case, "https://github.com/WireMock-Net/WireMock.Net/wiki/Scenarios-and-States#stay-in-the-same-state-for-a-number-of-requests" would be solution.

adam commented 2025-12-29 08:26:01 +01:00

Author

Owner

Copy Link

@edabreu commented on GitHub (Dec 4, 2020):

Hello @StefH

Thank you for clearing this issue. I've successfully created a test scenario as mentioned before using the Scenario states, but I've been trying to setup another scenario as follows:

this.wiremockServer.Given(Request.Create()
    .WithPath($"/search")
    .UsingPost())
    .InScenario("SearchFailureRecovery")
    .WillSetStateTo("Timeout failure", 1)
    .RespondWith(Response.Create()
    .WithHeader("Content-Type", "application/json")
    .WithBodyAsJson(searchResult)
    .WithStatusCode(200)
    .WithDelay(600));

this.wiremockServer.Given(Request.Create()
    .WithPath($"/search")
    .UsingPost())
    .InScenario("SearchFailureRecovery")
    .WhenStateIs("Timeout failure")
    .WillSetStateTo("Dependency Internal Server Error", 1)
    .RespondWith(Response.Create()
    .WithStatusCode(500));

this.wiremockServer.Given(Request.Create()
    .WithPath($"/search")
    .UsingPost())
    .InScenario("SearchFailureRecovery")
    .WhenStateIs("Dependency Internal Server Error")
    .RespondWith(Response.Create()
    .WithHeader("Content-Type", "application/json")
    .WithBodyAsJson(searchResult)
    .WithStatusCode(200));

On my service I have a timeout of 500ms. I can't manage to have this scenario working because the wiremock is stuck in the first state, always responding with a delay of 600ms for all retry attempts. I think that wiremock might not be updating its scenario state because my service is closing the connection due to timeout. Or am I doing something wrong?

@edabreu commented on GitHub (Dec 4, 2020): Hello @StefH Thank you for clearing this issue. I've successfully created a test scenario as mentioned before using the Scenario states, but I've been trying to setup another scenario as follows: ``` c# this.wiremockServer.Given(Request.Create() .WithPath($"/search") .UsingPost()) .InScenario("SearchFailureRecovery") .WillSetStateTo("Timeout failure", 1) .RespondWith(Response.Create() .WithHeader("Content-Type", "application/json") .WithBodyAsJson(searchResult) .WithStatusCode(200) .WithDelay(600)); this.wiremockServer.Given(Request.Create() .WithPath($"/search") .UsingPost()) .InScenario("SearchFailureRecovery") .WhenStateIs("Timeout failure") .WillSetStateTo("Dependency Internal Server Error", 1) .RespondWith(Response.Create() .WithStatusCode(500)); this.wiremockServer.Given(Request.Create() .WithPath($"/search") .UsingPost()) .InScenario("SearchFailureRecovery") .WhenStateIs("Dependency Internal Server Error") .RespondWith(Response.Create() .WithHeader("Content-Type", "application/json") .WithBodyAsJson(searchResult) .WithStatusCode(200)); ``` On my service I have a timeout of 500ms. I can't manage to have this scenario working because the wiremock is stuck in the first state, always responding with a delay of 600ms for all retry attempts. I think that wiremock might not be updating its scenario state because my service is closing the connection due to timeout. Or am I doing something wrong?

adam commented 2025-12-29 08:26:01 +01:00

Author

Owner

Copy Link

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

Quick answer: .WithHeader("Content-Type", "application/json") should also be added to the second part ?

And what you can do is observe the logging, maybe you see some details there why is it's not matching?

@StefH commented on GitHub (Dec 4, 2020): Quick answer: `.WithHeader("Content-Type", "application/json")` should also be added to the second part ? And what you can do is observe the logging, maybe you see some details there why is it's not matching?

adam commented 2025-12-29 08:26:01 +01:00

Author

Owner

Copy Link

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

Thank you for all the help.

@edabreu commented on GitHub (Dec 11, 2020): Thank you for all the help.

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 question

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#318