Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: optionally fail request if several mappings match #2263

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

tomasbjerre
Copy link
Contributor

@tomasbjerre tomasbjerre commented Jul 12, 2023

This PR adds a feature that, if enabled, will fail requests if several mappings are matched.

I have found myself, several times, trying to understand why some mapping is not working and later come the the conclusion that some other mapping was serving the request. This would help me reduce time spent on such problems.

References

wiremock/wiremock.org#127

Would also solve #2565

Submitter checklist

  • The PR request is well described and justified, including the body and the references
  • The PR title represents the desired changelog entry
  • The repository's code style is followed (see the contributing guide)
  • Test coverage that demonstrates that the change works as expected
  • For new features, there's necessary documentation in this pull request or in a subsequent PR to wiremock.org

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requesting changes, There is a bunch of API breaking changes that are IMHO not needed. QUite opposite, maybe it is better to have a withFailIfMultipleMappingsMatch(boolean) notation and to take a default value from a static final variable that we could make customizable later once WireMock gets full configuration engine

I also mentioned a bunch or refactorings in the code. No strong opinion about them

@@ -136,4 +136,6 @@ default Function<Extensions, NotMatchedRenderer> getNotMatchedRendererFactory()
Set<String> getTemplatePermittedSystemKeys();

boolean getTemplateEscapingDisabled();

boolean failIfMultipleMappingsMatch();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs a default return if we do not want to break binary compatibility of a public interface

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also should be failIfMultipleMappingsMatch() to follow the pattern

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fixed

@@ -139,7 +140,8 @@ public WireMockApp(
Map<String, ResponseDefinitionTransformerV2> v2transformers,
Map<String, RequestMatcherExtension> requestMatchers,
FileSource rootFileSource,
Container container) {
Container container,
boolean failIfMultipleMappingsMatch) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Breaks binary compatibility too. Maybe it is time to start switching to the public withFailIfMultipleMappingsMatch(boolean) pattern for new fields that are not critical to set?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

So WiremockApp has 2 constructors, perhaps the one taking Options is newer and the one taking booleans should be marked as @Deprecated? Anyway, I added the withFailIfMultipleMappingsMatch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me.


subEvents.forEach(initialServeEvent::appendSubEvent);

scenarios.onStubServed(matchingMapping);
this.scenarios.onStubServed(matchingMapping);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bunch of unrelated refactorings, but not blocking the PR because of it. I see no strict need to use this. in the code or in the code style though

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, this was a save action. Removing those changes.

@@ -33,14 +33,16 @@ public StoreBackedStubMappings(
Map<String, ResponseDefinitionTransformer> transformers,
Map<String, ResponseDefinitionTransformerV2> v2transformers,
BlobStore filesBlobStore,
List<StubLifecycleListener> stubLifecycleListeners) {
List<StubLifecycleListener> stubLifecycleListeners,
boolean failIfMultipleMappingsMatch) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

breaking change too

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@tomakehurst
Copy link
Member

Let's be careful about merging this one as it's changing the most performance-sensitive part of the codebase

@tomasbjerre
Copy link
Contributor Author

Perhaps some of the API comments here would have been avoided if the things that are considered API is in its own Gradle project, as discussed in #2266 .

@tomasbjerre
Copy link
Contributor Author

Requesting changes, There is a bunch of API breaking changes that are IMHO not needed. QUite opposite, maybe it is better to have a withFailIfMultipleMappingsMatch(boolean) notation and to take a default value from a static final variable that we could make customizable later once WireMock gets full configuration engine

I also mentioned a bunch or refactorings in the code. No strong opinion about them

I'm not sure I understand what you mean here exactly.

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All key comments are addressed. I guess now we need a call on the performance overhead, but I have no objections otherwise

P.S: We have no perf tests to do measurements

@@ -136,4 +136,8 @@ default Function<Extensions, NotMatchedRenderer> getNotMatchedRendererFactory()
Set<String> getTemplatePermittedSystemKeys();

boolean getTemplateEscapingDisabled();

default boolean failIfMultipleMappingsMatch() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class uses mixed patterns but I guess getSomething() dominates. Should it be getFailIfMultipleMappingsMatch() . No strong opinion

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement needs-tom Tom's Train Project :)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants