Expose FirstRunID in WorkflowExecutionInfo under DescribeWorkflowExecutionResponse

[dhiaayachi]

Is your feature request related to a problem? Please describe. I need to workaround with issue that runId is not stable after continueAsNew or reset. It's available in https://github.com/temporalio/sdk-go/blob/1f0296cdf9d7655269beed439ad1769dd8040654/internal/workflow.go#L1072 but I also need it from describeWF API

Describe the solution you'd like Add it in the api and then server

Describe alternatives you've considered No easy alternative currently (unless I redesign and rebuild the system:( )

Additional context More context of my current workflows running in production (needed in https://github.com/indeedeng/iwf/issues/404 ) When workflowA is running, it may kickoff a workflowA1 as a child workflow and then waiting for external to signal A1. A1 is currently based on A's workflowID+"number suffix". However, this is not sufficient when workflowA us using IdReusePolicy to reuse the workflowID.

This could be fixed if we can use firstRunId instead. Using currentRunID will not work because of continueAsNew and reset.

[dhiaayachi]

Feature Request: Stable RunId for Workflow Description API

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

The current runId for a workflow is not stable after a continueAsNew or reset operation. This issue creates a need for a stable identifier to track and manage workflows in situations where workflowId is reused (e.g., due to IdReusePolicy).

For example, the continueAsNew operation creates a new workflow execution with a new runId while retaining the same workflowId. This makes it difficult to track the history of a workflow across multiple runs, especially when the same workflowId is reused.

Describe the solution you'd like

Implement a mechanism to provide a stable runId for workflow description API calls. This would involve:

1. Adding firstRunId to the workflow description API: This would return the runId of the first execution within a workflow chain.
2. Server-side implementation: The Temporal server would need to be updated to store and retrieve the firstRunId for each workflow.

Describe alternatives you've considered

Currently, there is no easy alternative to fix this issue.

Additional context

This problem impacts workflows in production that use child workflows and rely on stable identifiers for managing workflow executions. For example, consider the following scenario:

• Workflow A is running and starts a child workflow A1 based on a naming convention of workflowId+"number suffix".
• Workflow A reuses its workflowId due to IdReusePolicy.
• This naming convention no longer functions correctly because workflow A will have a different runId after continueAsNew or reset.

Using firstRunId instead of the current runId would solve this issue by providing a stable identifier for the entire workflow chain, regardless of continueAsNew or reset operations.

References:

• GitHub Issue
• Indeed Engineering iwf issue

This feature request would greatly enhance the ability to track and manage workflows in situations where workflowId is reused. It would also improve the stability and reliability of workflows in complex scenarios involving child workflows and multiple runs.

[dhiaayachi]

Thanks for reporting this issue! It looks like you're looking for a way to access the first run ID of a workflow using the describeWF API. Currently, the API doesn't expose this information. However, the information is available in the Workflow Execution Started Event (which the describeWF API returns), as part of the first_execution_run_id field.

Let me know if you have any more questions.