Question: Stub priority - Most recent stub is not always used #91

New Issue

adam · 2025-12-29T08:22:08+01:00

adam commented

2025-12-29 08:22:08 +01:00

Originally created by @FSatmar on GitHub (Apr 19, 2018).

Originally assigned to: @StefH on GitHub.

Hi Stef.
It seems that when you have multiple stubs matching the same request, the most recent one is not always used (as expected according to https://github.com/WireMock-Net/WireMock.Net/wiki/Stubbing-and-Request-Matching#stub-priority). Happens to me quite often in tests where I create new stub with diffrent version number for example.
Could you pls check it?

Originally created by @FSatmar on GitHub (Apr 19, 2018). Originally assigned to: @StefH on GitHub. Hi Stef. It seems that when you have multiple stubs matching the same request, the most recent one is not always used (as expected according to https://github.com/WireMock-Net/WireMock.Net/wiki/Stubbing-and-Request-Matching#stub-priority). Happens to me quite often in tests where I create new stub with diffrent version number for example. Could you pls check it?

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

adam closed this issue

2025-12-29 08:22:08 +01:00

adam commented

2025-12-29 08:22:09 +01:00

@StefH commented on GitHub (Apr 19, 2018):

The stub-priority should work if you set the priority as described in that chapter.

If you add more mappings which match the same request, there is no logic to take to most recent, I guess you get a random one back...

Does this help you?

@StefH commented on GitHub (Apr 19, 2018): The stub-priority should work if you set the priority as described in that chapter. If you add more mappings which match the same request, there is no logic to take to most recent, I guess you get a random one back... Does this help you?

adam commented

2025-12-29 08:22:09 +01:00

@FSatmar commented on GitHub (Apr 20, 2018):

Oh ok, I just read "By default, WireMock.NET will use the most recently added matching stub to satisfy the request." and assumed it's not necessary to use priority if you just always want the latest stub. But anyway, I should be able to increase priority with every 'update'.

@FSatmar commented on GitHub (Apr 20, 2018): Oh ok, I just read "By default, WireMock.NET will use the most recently added matching stub to satisfy the request." and assumed it's not necessary to use priority if you just always want the latest stub. But anyway, I should be able to increase priority with every 'update'.

adam commented

2025-12-29 08:22:09 +01:00

@StefH commented on GitHub (Apr 20, 2018):

Ah, ok. I see.
Probably I did copy this from the wiremock.org website, I'll take a look if it's easy to really implement this functionality in the code.

@StefH commented on GitHub (Apr 20, 2018): Ah, ok. I see. Probably I did copy this from the wiremock.org website, I'll take a look if it's easy to really implement this functionality in the code.

adam commented

2025-12-29 08:22:10 +01:00

@FSatmar commented on GitHub (Apr 20, 2018):

Btw, wouldn't it make sense to simply overwrite the stub when the new one matches the same request pattern?

@FSatmar commented on GitHub (Apr 20, 2018): Btw, wouldn't it make sense to simply overwrite the stub when the new one matches the same request pattern?

adam commented

2025-12-29 08:22:10 +01:00

@StefH commented on GitHub (Apr 20, 2018):

If you want to overwrite the same, you have to provide the same guid (in a PUT or POST).

Example:

{
    "Guid": "70000000-a633-40e8-a244-5cb80bc00001",
    "Request": {
    . . . .

@StefH commented on GitHub (Apr 20, 2018): If you want to overwrite the same, you have to provide the **same** `guid` (in a PUT or POST). Example: ``` js { "Guid": "70000000-a633-40e8-a244-5cb80bc00001", "Request": { . . . . ```

adam commented

2025-12-29 08:22:10 +01:00

@FSatmar commented on GitHub (Apr 20, 2018):

Hm, that would make my test setup very complicated as I'm creating many different stubs for one test and then i'd have to keep track of the guids when I want to update one of them. For the time being I'll try using the priority as that seems easier to implement.

@FSatmar commented on GitHub (Apr 20, 2018): Hm, that would make my test setup very complicated as I'm creating many different stubs for one test and then i'd have to keep track of the guids when I want to update one of them. For the time being I'll try using the priority as that seems easier to implement.

adam commented

2025-12-29 08:22:10 +01:00

@StefH commented on GitHub (Apr 20, 2018):

You only need to provide the guid in the mapping which you can just add or update using http POST. So that should not be extra work.

Because if you define the same mapping, but with a different priority, the sever needs to keep all these mappings in memory, and when you want to view the mappings, you get a lot of mapping, and onlt the highest prio is used.

@StefH commented on GitHub (Apr 20, 2018): You only need to provide the `guid` in the mapping which you can just add or update using http POST. So that should not be extra work. Because if you define the same mapping, but with a different priority, the sever needs to keep all these mappings in memory, and when you want to view the mappings, you get a lot of mapping, and onlt the highest prio is used.

adam commented

2025-12-29 08:22:11 +01:00

@andreycha commented on GitHub (Apr 25, 2018):

If you want to overwrite the same, you have to provide the same guid (in a PUT or POST).

Hi,

I believe it would be easier and more consistent to overwrite existing mapping if Request part is exactly the same, it doesn't make sense to collect mappings with the same request part. Let me explain what I mean:

We create following mapping:

server
  .Given(Request.Create().WithPath("/some/operation"))
  .RespondWith(Responses.Create().WithStatusCode(404));

Later in the test we need that mapping to respond differently for the same type of request, so we just add new mapping with the same request setup:

server
  .Given(Request.Create().WithPath("/some/operation"))
  .RespondWith(Responses.Create().WithStatusCode(200));

Now we end up with two mappings which are picked up randomly. But in the scenario when everything is the same in request part, mapping can be safely overwritten.

@andreycha commented on GitHub (Apr 25, 2018): > If you want to overwrite the same, you have to provide the same guid (in a PUT or POST). Hi, I believe it would be easier and more consistent to overwrite existing mapping if Request part is _exactly the same_, it doesn't make sense to collect mappings with the same request part. Let me explain what I mean: 1. We create following mapping: ``` server .Given(Request.Create().WithPath("/some/operation")) .RespondWith(Responses.Create().WithStatusCode(404)); ``` 2. Later in the test we need that mapping to respond differently for the same type of request, so we just add new mapping with the same request setup: ``` server .Given(Request.Create().WithPath("/some/operation")) .RespondWith(Responses.Create().WithStatusCode(200)); ``` Now we end up with two mappings which are picked up randomly. But in the scenario when everything is the same in request part, mapping can be safely overwritten.

adam commented

2025-12-29 08:22:11 +01:00

@StefH commented on GitHub (Apr 26, 2018):

A]
I understand this. I'll check if it's possible to compare the mapping, this has to be built for the mappings defined in code (your example) and also has to implemented in the admin mappings via POST Mapping.

B]
As a workaround, you can use the same guid, so your code could be like:

server
  .Given(Request.Create().WithPath("/some/operation")).WithGuid("90356dba-b36c-469a-a17e-669cd84f1f05"))
  .RespondWith(Responses.Create().WithStatusCode(200));

@StefH commented on GitHub (Apr 26, 2018): **A]** I understand this. I'll check if it's possible to compare the mapping, this has to be built for the mappings defined in code (your example) and also has to implemented in the admin mappings via POST Mapping. **B]** As a workaround, you can use the same `guid`, so your code could be like: ``` c# server .Given(Request.Create().WithPath("/some/operation")).WithGuid("90356dba-b36c-469a-a17e-669cd84f1f05")) .RespondWith(Responses.Create().WithStatusCode(200)); ```

adam commented

2025-12-29 08:22:11 +01:00

@StefH commented on GitHub (May 19, 2018):

I just reread your comments and I noticed on your examples: operation 1 and operation 2 are different because they use a different status code.
So they ARE different, always.

What you want is that if the Request is the same, the mapping is overwritten with the latest most recent one.

This requires significant changes in the matching logic, so for now I would suggest to use the guid or priority.

And for now I will just delete the line By default, WireMock.NET will use the most recently added matching stub to satisfy the request. from the WIKI, because this is indeed not true.

@StefH commented on GitHub (May 19, 2018): I just reread your comments and I noticed on your examples: operation 1 and operation 2 are different because they use a different status code. So they **ARE** different, always. What you want is that if the **Request** is the same, the mapping is overwritten with the latest most recent one. This requires significant changes in the matching logic, so for now I would suggest to use the `guid` or `priority`. And for now I will just delete the line *By default, WireMock.NET will use the most recently added matching stub to satisfy the request.* from the WIKI, because this is indeed not true.

adam commented

2025-12-29 08:22:11 +01:00

@xadvfh commented on GitHub (Mar 1, 2021):

@StefH I know this is a closed issue but it is something that I'd also be interested in. Keeping track of GUIDs is, unfortunately, not always possible.

@xadvfh commented on GitHub (Mar 1, 2021): @StefH I know this is a closed issue but it is something that I'd also be interested in. Keeping track of GUIDs is, unfortunately, not always possible.

adam commented

2025-12-29 08:22:11 +01:00

@StefH commented on GitHub (Mar 2, 2021):

@xadvfh using an unique GUID is only way the tell mappings apart.

Else I need to check if some things match (like the path) and only change the part that does not match (the status code). This is very difficult.

The only thing I can maybe add is another unique identifier, which can be a string? But I'm not sure this helps you.

@StefH commented on GitHub (Mar 2, 2021): @xadvfh using an unique GUID is only way the tell mappings apart. Else I need to check if some things match (like the path) and only change the part that does not match (the status code). This is very difficult. The only thing I can maybe add is another unique identifier, which can be a string? But I'm not sure this helps you.

adam commented

2025-12-29 08:22:11 +01:00

@xadvfh commented on GitHub (Mar 2, 2021):

Understood. I think I can make using priority work. thank you.

@xadvfh commented on GitHub (Mar 2, 2021): Understood. I think I can make using priority work. thank you.

adam referenced this issue

2025-12-29 08:33:26 +01:00

[PR #92] [MERGED] Json fixes (#91) #761

Sign in to join this conversation.

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 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/WireMock.Net#91