search

temporalio / features

Behavior and history compatibility testing for Temporal SDKs
13 stars 17 forks source link

[Feature Request] Consider higher-level activity options for some languages #174

Open cretz opened 1 year ago

cretz commented 1 year ago

Is your feature request related to a problem? Please describe.

TypeScript and Java both support setting activity options at the workflow level for all activities of a type. Java even supports setting default activity options for all activities. Go and Python support neither of these.

Outstanding questions:

This intentionally doesn't discuss contextual activity options like only Go has or invocation time options like only Python has

bergundy commented 1 year ago

TypeScript and Java both support setting activity options at the workflow level for all activities of a type. Java even supports setting default activity options for all activities. Go and Python support neither of these.

In Python you can bake partial functions, that gives you the same semantics as the proxy and stub methods in TS and Java. I'd say the Python approach is superior and I would have liked to use the same in TS if we didn't have the restriction where we can't import the activity function into the sandbox.

Should we support workflow-level default activity options for TypeScript, Python, and Go?

TypeScript supported this in the pre-alpha stage, we removed this a long time ago. I definitely see some value in it since activity options are an implementation detail and shouldn't be the caller's concern. I would prefer a more generalized solution where workflow and activity options can be defined on the implementation side. I think that's what most users want.

cretz commented 1 year ago

This request was initially made by @mfateev in a more narrowly scoped way - Should we provide something like https://www.javadoc.io/static/io.temporal/temporal-sdk/1.17.0/io/temporal/worker/WorkflowImplementationOptions.Builder.html#setActivityOptions(java.util.Map) in Go? I just expanded the scope of the discussion to make sure I captured it. I have no problem leaving each language to its own approach here.

As concepts of Go get potentially redesigned, I think it's clear that invoking an activity or child workflow should accept options for that activity or child workflow at the call site not in context. But that isn't changing anytime soon. And of course support for definition-site options aren't happening anytime soon.