Better guidance when WhenSagaTimesOut is used without previous RequestTimeout

[danielmarbach]

Who's affected

• Users trying to use WhenSagaTimesOut without previous call to When or WhenHandle

Symptoms

Test.Saga<TimeoutSaga>()
                    .ExpectTimeoutToBeSetIn<MyTimeout>((state, expiresIn) => expiresIn == TimeSpan.FromDays(1))
                    .WhenSagaTimesOut()

will throw a KeyNotFoundException coming from the TimeoutManager. The problem is that this exception doesn't guide the user in any way to do the right thing.

[danielmarbach]

@Particular/nservicebus-maintainers is it safe to assume we will never enqueue a null timeout state?

[timbussmann]

is this worth a hotfix? What about v6?

[danielmarbach]

I would release it as a patch. Not a hotfix.

[danielmarbach]

Happy to rebase this to current release branch. I added it as a patch because a customer was falling over that exception and didn't know how to resolve it. The consequence was, I received an email. So fixing this would potentially prevent similar interactions in the future because it is much clearer how the API should be called.

[timbussmann]

Happy to rebase this to current release branch

👍 to that. The approach in core was to fix non-criticals on the release branch. I think we should follow that process in testing.

[danielmarbach]

Pre-release doesn't have this problem. It throws an ExpectedInvocation exception.

[danielmarbach]

Let's release this small patch next week?

[timbussmann]

@danielmarbach should we copy the test over to develop?

[danielmarbach]

If you think there is value in it why not.

[timbussmann]

5.2.1 is now released