Summary
Follow-up to #76.
The current durable HITL response path forwards exactly the response payload supplied by the caller. That behavior is understood and can remain the default. However, with partial approval payloads, downstream executors receive a newly deserialized partial TInput, so fields that existed before suspension can be reset unless the caller resends the full object or the workflow reconstructs it from shared state.
This proposes an opt-in merge/overlay behavior for durable HITL resume: preserve the pre-suspension executor input and overlay only the fields supplied by the approval response.
Example
Original executor input:
{
"id": "ABC-123",
"inputnumber": "42",
"isapproved": false
}
Approval response:
{
"isapproved": true
}
Current downstream payload:
{
"id": "",
"inputnumber": "",
"isapproved": true
}
Proposed opt-in merged payload:
{
"id": "ABC-123",
"inputnumber": "42",
"isapproved": true
}
Desired behavior
The approval response should update only the subset of state it owns, while the durable resume path preserves the semantic executor input that existed before suspension.
A useful invariant is:
Executor receives TInput X
→ workflow suspends for HITL
→ approval response updates owned fields
→ workflow resumes
→ all non-approval-owned fields of X are preserved
Possible API shapes
To preserve backward compatibility, this could be exposed as one of:
an opt-in RequestPort merge/overlay mode;
an explicit response merge policy;
a helper that restores the original request and applies the partial approval response before forwarding downstream.
The existing behavior of forwarding exactly what the caller sends can remain the default.
Why this helps
For larger workflow inputs, requiring every HITL caller to resend many unrelated fields couples the approval transport to the full executor state shape.
Shared state with a stable key is a valid workaround, but an explicit merge policy would make the resume contract clearer and reduce repeated reconstruction logic.
Scope
This is an enhancement proposal, not a claim that the current behavior is incorrect.
It follows the maintainer discussion in #76, where automatic merging of partial responses with the original request was identified as a possible improvement.
Related: #76
Summary
Follow-up to #76.
The current durable HITL response path forwards exactly the response payload supplied by the caller. That behavior is understood and can remain the default. However, with partial approval payloads, downstream executors receive a newly deserialized partial
TInput, so fields that existed before suspension can be reset unless the caller resends the full object or the workflow reconstructs it from shared state.This proposes an opt-in merge/overlay behavior for durable HITL resume: preserve the pre-suspension executor input and overlay only the fields supplied by the approval response.
Example
Original executor input:
{ "id": "ABC-123", "inputnumber": "42", "isapproved": false } Approval response: { "isapproved": true } Current downstream payload: { "id": "", "inputnumber": "", "isapproved": true } Proposed opt-in merged payload: { "id": "ABC-123", "inputnumber": "42", "isapproved": true } Desired behavior The approval response should update only the subset of state it owns, while the durable resume path preserves the semantic executor input that existed before suspension. A useful invariant is: Executor receives TInput X → workflow suspends for HITL → approval response updates owned fields → workflow resumes → all non-approval-owned fields of X are preserved Possible API shapes To preserve backward compatibility, this could be exposed as one of: an opt-in RequestPort merge/overlay mode; an explicit response merge policy; a helper that restores the original request and applies the partial approval response before forwarding downstream. The existing behavior of forwarding exactly what the caller sends can remain the default. Why this helps For larger workflow inputs, requiring every HITL caller to resend many unrelated fields couples the approval transport to the full executor state shape. Shared state with a stable key is a valid workaround, but an explicit merge policy would make the resume contract clearer and reduce repeated reconstruction logic. Scope This is an enhancement proposal, not a claim that the current behavior is incorrect. It follows the maintainer discussion in #76, where automatic merging of partial responses with the original request was identified as a possible improvement. Related: #76