[Feature Request] Workflow current details and static metadata

[chris-olszewski]

No set_current_details() / current_details() for dynamically updating workflow metadata during execution. No static_summary / static_details at workflow start.

[sachinsharma3191]

Design Proposal: Workflow Current Details & Static Metadata

This document outlines an implementation path for supporting both static and dynamically updatable metadata fields for workflows in the Core SDK.

1. Static Metadata (Initialization Phase)

• Client Configuration: Expand the StartWorkflowOptions struct to include static_summary (String) and static_details (String or standard Payload).
• gRPC Wiring: The core gRPC layer maps these new SDK-level fields into the standard Temporal StartWorkflowExecutionRequest.
• Worker Injection: Upon the first workflow activation, the WorkflowInfo structure provided into the user's workflow context should be automatically hydrated with these fields. This allows immediate, deterministic access via workflow::info().static_summary() the moment a workflow runs.

2. Dynamic Details (Execution Phase)

• Dynamic Mutator (set_current_details): Introduce an SDK API, workflow::set_current_details(payload), which updates the workflow's real-time visibility record.
• Core State Machine: Calling this API should issue an UpdateWorkflowExecutionOptions command internally. The Core execution tracker will batch this command with other outbound events, dispatching it to the server at the next WFT completion heartbeat.
• Local Read-State (current_details): To preserve workflow context efficiently without network fetches, cache the updated dynamically active details inside the isolated workflow state runtime memory block. Calling current_details() simply reads this synchronized caching variable instantaneously.

3. Forward Compatibility & Payload Handling

• Currently, static and dynamic fields conventionally accept UTF-8 strings in older designs, but Temporal is driving towards formal JSON Payloads for static_details.
• The design should permit utilizing the registered PayloadConverter traits (proposed/available in the ecosystem) rather than assuming raw strings, ensuring cross-lang interoperability when filtering executions based on static tokens.

[sachinsharma3191]

@chris-olszewski, whenever you have a moment, could you take a look at the design for this? Also, let me know if you’re already tackling this so we don't double up on effort.