Is your feature request related to a problem? Please describe.
In the Java SDK, you have an @ActivityInterface with multiple @ActivityMethods. The latter is the actual unit of execution. However, you specify retry and timeout options on the activity stub, which is based on the interface, so in order to have specific config for each activity you have to go out of your way and break up the interface into small pieces, which kinda defeats one of the nicest features of Temporal which is to just program your service as if it were native code. You can configure specific settings per method, but you have to use strings for activity names instead of strongly typed constructs, and still the activity-stub level config takes precedence.
Recently, I became aware of the @MethodRetry annotation, which is great, but it only allows you to specify retry options, not timeouts, so it falls short of addressing the basic issue.
Describe the solution you'd like
Either an additional set of parameters in @MethodRetry or a new annotation (e.g. @ActivityTimeouts) that allows me to specify activity timeouts (start-to-close and schedule-to-close) at the method level.
Describe alternatives you've considered
Specifying per-activity config using WorkflowImplementationOptions, but you have to use strings for activity names instead of strongly typed constructs, and still the activity-stub level config takes precedence.
Is your feature request related to a problem? Please describe. In the Java SDK, you have an
@ActivityInterfacewith multiple@ActivityMethods. The latter is the actual unit of execution. However, you specify retry and timeout options on the activity stub, which is based on the interface, so in order to have specific config for each activity you have to go out of your way and break up the interface into small pieces, which kinda defeats one of the nicest features of Temporal which is to just program your service as if it were native code. You can configure specific settings per method, but you have to use strings for activity names instead of strongly typed constructs, and still the activity-stub level config takes precedence.Recently, I became aware of the
@MethodRetryannotation, which is great, but it only allows you to specify retry options, not timeouts, so it falls short of addressing the basic issue.Describe the solution you'd like Either an additional set of parameters in
@MethodRetryor a new annotation (e.g.@ActivityTimeouts) that allows me to specify activity timeouts (start-to-close and schedule-to-close) at the method level.Describe alternatives you've considered Specifying per-activity config using WorkflowImplementationOptions, but you have to use strings for activity names instead of strongly typed constructs, and still the activity-stub level config takes precedence.
Additional context N/A.