I was wondering when you create the ActivityStub is there a reason why we can’t configure the activityId in the ActivityOptions. We are able to do it at the when creating a new workflow stub via WorkflowOptions. It seems natural that ActivityOptions should cover it as well.
Being able to set the activityId can be useful. For example, I generate activities in a cancel scope and rely on signals coming into the workflow to cancel the activity. In this case, the workflow contains an internal mapping between the cancel scope and some sort of ID associated with the activity. Since I don’t know the activity ID since I can’t set it in the Workflow scope, I’m forced to pass in a generated UUID into the activity method. This activity method will tell the external service this UUID so it can use it to signal the workflow to cancel the activity.
However, if i was able to set the activity ID when starting it, this will make this whole flow a lot easier.
Activity Ids have to be unique in Java SDK because currently there is no way to specify it via ActivityOptions - see Support passing activityId to an activity invocation · Issue #86 · temporalio/sdk-java · GitHub. Until this feature is added, the activity id is generated.
You register a single activity impl with your workers, so each activity invocation uses that same instance (thus your activity code should be thread-safe :)).
You can get the activity id inside activity methods via:
Another idea is that since your activities that you want to cancel have to heartbeat, from outside of workflow you can use DescribeWorkflowExecution call that returns all pending activities information including data included in the last heartbeat. This could help with your activities not to have to notify the external service directly.
