Closed NateLehman closed 2 months ago
/azp run
/azp run
/azp run
/azp run
/azp run
There's now a successful pipeline run associated with this PR.
I think there are some details about the GitHub<->Azure DevOps integration that I'm not familiar with. It looks like this is being blocked from merging based on a previous run.
/azp run
/azp run
I manually ran the DTFx Build & Run Tests (ServiceBus)
pipeline and confirmed that it's also green. Merging.
Validation strategies for .NET Core version
It has come to my attention that the .NET Core version of this library needs additional validation. This section describes validations performed manually.
Leveraging a real world prod service
Without revealing much about our internal design, my team uses DTF ServiceBus for running workflows in a .NET Core project. I've locally sideloaded this new version into a worker service running in a dev environment that consumes real world application orchestrations.
The tasks and orchestrations consumed by the worker running with the sideloaded library did not produce unhandled exceptions and did not behave in any way that suggested issues. Additionally, the worker was running in concert with other worker instances that were running the current stable version without Azure.Messaging.ServiceBus; I consider this a testament to its compatibility.
Running DurableTask.ServiceBus.Tests project
I also set up live ServiceBus and AzureStorage resources in my own Azure subscription and added their connections strings to the project. This allowed me to run the DurableTask.ServiceBus.Tests(netcoreapp3.1) project against real world resources and validate those scenarios. I am attaching a VSTest overview screenshot as proof of these results:![image](https://github.com/Azure/durabletask/assets/9384649/fc3ffe36-596f-4d59-80cc-093386560270)
NOTE: All of the failing tests in this image are ALSO failing in the previous stable version (when I switch to
main
branch).