GUIDs generated by WireMock.NET differ between instances when deployed to Azure with multiple instances.

[fenildesai]

Describe the bug

When deploying an application using WireMock.NET to Azure with multiple instances, we've observed that the GUIDs generated by WireMock.NET differ between instances. This inconsistency leads to requests not matching the expected stub mappings, resulting in unexpected behavior such as 404 errors.

Expected behavior:

We expect WireMock.NET to generate consistent GUIDs for stub mappings across all instances, ensuring that requests are properly matched to the appropriate stub responses regardless of the instance handling the request.

Test to reproduce

1. Deploy an application using WireMock.NET to Azure with multiple instances.
2. Send requests to the deployed application.
3. Observe that the GUIDs generated by WireMock.NET differ between instances.
4. Notice that requests do not match the expected stub mappings, leading to 404 errors.

Other related info

We have session affinity enabled in the Azure App Service configuration to ensure that requests from the same client are consistently routed to the same instance.

[StefH]

Note that each WireMock.Net instance saves the mappings in memory from that instance. And if a GUID is generated by WireMock.Net, it's just a random GUID.

However I'm not sure I understand why you have issues with GUIDs? Do you run WireMock.Net in proxy mode or in normal mode?

Because when adding stub-mappings via C# code, mapping file or admin interface, you can provide a guid. If the guid is not provided, a random guid is used.

[StefH]

@fenildesai
Is my explanation clear?

[StefH]

@fenildesai
Is my explanation clear?