Can a saga find out its own ID in 3.x?

In our Axon 2 code, a couple of our sagas schedule timeout events for themselves. Since the timeouts are only of interest to those specific saga instances, we use event classes with "sagaIdentifier" fields to guarantee that the events aren't broadcast to other event handlers. The sagas call getSagaIdentifier() to get their IDs.

Under Axon 3, I don't see a "get my ID" method in the static-importable saga lifecycle class that sagas are supposed to use instead of subclassing AbstractAnnotatedSaga. Is there a public API for that? If not, is it a reasonable request, or should I be taking a different approach?

I know there's discussion of a deadline API that is supposed to solve the "a specific component wants to be notified when X amount of time passes, and the notification isn't of any interest to other components" problem, but unless I'm mistaken, that is still in the planning stages and the event scheduler is how we're supposed to solve this right now.

For what it's worth, we started using this approach after we added a saga class that associated with the same aggregate ID as an existing saga class and needed to time out on the same kind of operation as the existing saga. Without thinking through the implications, we used the existing timeout event class and, of course, the sagas started getting each other's scheduled events and running their timeout logic at the wrong times. Using the saga ID seemed like a good way to make similar bugs impossible in the future.


Hi Steven,

my first thought was: just do SagaLifecycle.getInstance(), but it’s a protected method. Making that method public won’t help.
It looks like the identifier is kept private. We never really saw a need to publish the identifier.

I don’t see any objections in making the identifier visible somehow. Your use case sounds reasonable and it will probably also help with the Deadline API that we are planning to add in the future (where deadlines are slightly different messages that will only reach the instance that scheduled it).

As a workaround/alternative, you might consider adding an explicit field to your Saga that contains a random value. That value could be initialized on the @StartSaga handlers.