Add suspend/resume tests #3028
Add suspend/resume tests #3028
Conversation
| Thread.Sleep(1000); | ||
|
|
||
| var orchestrationDetails = await DurableHelpers.GetRunningOrchestrationDetailsAsync(statusQueryGetUri); | ||
| Assert.Equal("Running", orchestrationDetails.RuntimeStatus); |
There was a problem hiding this comment.
Rather than sleeping and hoping that the status will change after the sleep interval, we can make these checks a bit more reliable and potentially faster if we use a polling pattern to check for the state change. This would address the very common flakey test problem where engineers need to increase sleep durations because things ran slower than we expected. Consider creating a helper method that can wait for an orchestration to transition from one state to another (Pending --> Running, Running --> Suspended, Suspended --> Running, etc.)
There was a problem hiding this comment.
Done. Feel free to critique my implementation
| try | ||
| { | ||
| using HttpResponseMessage suspendResponse = await HttpHelpers.InvokeHttpTrigger("SuspendInstance", $"?instanceId={instanceId}"); | ||
| await AssertRequestFailsAsync(suspendResponse); |
There was a problem hiding this comment.
A couple things:
- The method
AssertRequestFailsAsyncassumes that the request is a termination request, but you're sending a suspend request. - What's the expected behavior for in-proc? Do we throw if you try to suspend a suspended orchestration? I was hoping we wouldn't, but if we are, then checking for a failure message is fine.
There was a problem hiding this comment.
- The behavior is the same, but I've updated the parameters and variable names to reflect this.
- Yes, we throw in the same way for in-proc (except with a more verbose exception message, as described in the bug linked in the comments)
Adds testing for suspend/resume in Durable
Pull request checklist
pending_docs.mdrelease_notes.md/src/Worker.Extensions.DurableTask/AssemblyInfo.csdevandmainbranches and will not be merged into thev2.xbranch.