🧰 Additional APIs
Description
Provide APIs for additional functionality that users need that doesn't align with the purpose and interface of WorkflowClient.
APIs to be used for implementation of Workflows and Activities don't belong to this Epic
Core Objectives
Temporal support chats and forums are filled with code snippets that we provide for our users to achieve this and that goal. It's usually some wrappers around the raw gRPC endpoints that are too non-intuitive for users.
We don't implement this functionality as a normal SDK API because it's not a part of normal Workflow implementations and they don't below to WorkflowClient interface. At the same time, we don't have any other class/interface to expose it on and there is no system in place to make this process manageable.
SDK should systematize and expose such functionality and provide a reasonable structure of interfaces and classes to access it.
Tasks
- [ ] #1036
Related user requests / reports
- [x] #835
- [ ] describeWorkflowExecution. Some users were using our internal method for that: https://github.com/temporalio/sdk-java/issues/1028
@Spikhalskiy most of these utility methods are documented here: https://github.com/tsurdilo/temporal-java-workshop/blob/main/src/main/java/io/workshop/c1s1/S1WFUtils.java
so things like:
getWorkflowStatus getActivitiesWithRetriesOver getLastHistoryEvent getFirstHistoryEvent printFailedWorkflowsWithReason resetWorkflow terminateWorkflow ...
are things that i think we could create util methods for. Basically we should have a 1-1 mapping between tctl commands and out-of-box util methods in our sdk imo. This should at some point also please include admin apis that are currently not exposed via proto in sdks.
There is also one recent post on forum where user asked to get search attributes for specific id: https://community.temporal.io/t/search-attributes-always-null-when-fetched-from-service-library/3892/2 that would be nice to add as util method out of box as well
the "List" APIs are not really that bad, the problem is that noone knows/thinks of pagination and page size. i think these util methods we add should handle pagination out of box so people don't have to think about it or forget and see issues.
another thing that would be really nice is to make it absolutely clear which "List" apis can be used with/without Elasticsearch enabled.
sorry one more :) in addition we should document apis to make it clear that those using enhanced visibility store are eventually consistent and may have delays compared to what users see in web ui or via tctl when querying persistent store