feat!: Make the messaging provider handle scenario requests async#537
Draft
adamrodger wants to merge 1 commit intodev/async-message-factoryfrom
Draft
feat!: Make the messaging provider handle scenario requests async#537adamrodger wants to merge 1 commit intodev/async-message-factoryfrom
adamrodger wants to merge 1 commit intodev/async-message-factoryfrom
Conversation
There was a problem hiding this comment.
Copilot reviewed 12 out of 17 changed files in this pull request and generated 1 comment.
Files not reviewed (5)
- samples/OrdersApi/Consumer.Tests/Consumer.Tests.csproj: Language not supported
- samples/OrdersApi/Provider.Tests/Provider.Tests.csproj: Language not supported
- src/PactNet.Abstractions/PactNet.Abstractions.csproj: Language not supported
- tests/PactNet.Abstractions.Tests/PactNet.Abstractions.Tests.csproj: Language not supported
- tests/PactNet.Tests/PactNet.Tests.csproj: Language not supported
Comments suppressed due to low confidence (1)
src/PactNet/Verifier/Messaging/MessagingProvider.cs:94
- Returning null from the Start method when the cancellation token is triggered could lead to a null reference error in the caller. Consider throwing an exception or restructuring the control flow to handle this case explicitly.
return null;
tests/PactNet.Tests/Verifier/Messaging/MessageScenariosTests.cs
Outdated
Show resolved
Hide resolved
7686959 to
3cf1914
Compare
This removes a wrinkle in the API whereby scenario factory methods can be async internally, but because the messaging provider was sync we had to do a sync-over-async call to generate those scenarios. Instead, now the messaging provider runs in an async context, which means the API has changed such that async scenario factory methods are now the default internally. Any sync scenario factories are wrapped such that they become async with `Task.FromResult`. This creates a breaking API change because the verifier and the messaging provider were both previously sync disposable, whereas now they're async disposable so the the messaging prodiver can stop the async request handling context.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This removes a wrinkle in the API whereby scenario factory methods can be async internally, but because the messaging provider was sync we had to do a sync-over-async call to generate those scenarios.
Instead, now the messaging provider runs in an async context, which means the API has changed such that async scenario factory methods are now the default internally. Any sync scenario factories are wrapped such that they become async with
Task.FromResult.This creates a breaking API change because the verifier and the messaging provider were both previously sync disposable, whereas now they're async disposable so the the messaging prodiver can stop the async request handling context.