Add firstExecutionRunId to system search attribute

[dhiaayachi]

Is your feature request related to a problem? Please describe. Right now runId is always changed when :

• ContinueAsNew
• Reset
• Cron
• WorkflowRetry

However, user have to rely on runId to distinguish different executions when using IdReusePolicy. For example, user starts two different runs with IdReusePolicy, and they are both completed after certain reset or continueAsNew.

Now user wants to query the final workflow results for different runs.

Describe the solution you'd like User can provide the firstExecutionRunId to find out the last runId (filter by completed or running status) to find out the last runId. And then use the final runId to query the workflows

Describe alternatives you've considered User can do search attribute themselves, but it's repeated work.

Additional context NA

[dhiaayachi]

Thanks for reporting this issue. I understand that you're looking for a way to distinguish between different workflow executions when using IdReusePolicy and having operations like ContinueAsNew, Reset, and Cron that change the runId.

Currently, Temporal does not have a built-in mechanism to directly get the last runId based on the first execution runId. However, here's a possible workaround:

1. Use a custom workflow state: You can store the runId of the first execution in a custom workflow state. This allows you to track the initial runId across multiple executions and avoid needing to rely on the first runId alone for queries.

2. Implement a custom query: You can define a custom query that utilizes the workflow state to filter for workflows based on the initial runId. This custom query can help you retrieve workflows that have gone through multiple ContinueAsNew, Reset, or Cron operations while still identifying them based on their initial runId.

You can learn more about defining custom queries in Temporal by referring to the documentation: https://docs.temporal.io/docs/typescript/guides/workflows/#queries

This approach might require some code changes to your workflow and query implementation, but it can address your need to track workflows across different executions even when the runId changes.

[dhiaayachi]

Thank you for your feature request!

This is a great suggestion for enhancing workflow identification. Currently, runId changes under the circumstances you outlined. While this is the default behavior, you can achieve your desired workflow distinction using IdReusePolicy in conjunction with the WorkflowExecutionInfo API.

Here's how you can achieve this:

1. Start your workflow with a specific runId: Use the WorkflowOptions to specify a runId when starting a workflow.
2. Utilize WorkflowExecutionInfo: Query the WorkflowExecutionInfo using the initial runId and WorkflowId. This will provide you with the most recent runId.
3. Filter workflows: You can then use this latest runId to query for the final results of your workflow.

This method allows you to manage workflow distinction effectively.

While there is no direct API to accomplish this task in Temporal, we are open to exploring this functionality further. We appreciate your feedback and will keep it in mind for future development.

[dhiaayachi]

Thank you for raising this feature request! I understand that you want to be able to identify the final runId for a workflow with IdReusePolicy, even after operations like ContinueAsNew, Reset, Cron, or WorkflowRetry.

Currently, Temporal doesn't directly support this functionality. However, you can achieve a similar outcome by using workflow search attributes. Here's how:

1. Store the initial runId as a search attribute: When the workflow starts, store the initial runId in a search attribute.
2. Query for the final runId: You can query for workflows with the specific initial runId and then use the query to retrieve the final runId.

Let me know if you have any other questions or if you'd like to explore this approach further.