Summary
Functional workflows accept a response whose runtime type does not match the response_type declared in RunContext.request_info() during response-only HITL resume.
Reproduction
from agent_framework import RunContext, workflow
@workflow
async def typed_review(data: str, ctx: RunContext) -> str:
answer = await ctx.request_info("number", response_type=int, request_id="typed")
return f"{answer}:{type(answer).__name__}"
caller = typed_review.build()
await caller.run("input")
resumed = await caller.run(responses={"typed": "not-an-int"})
print(resumed.get_outputs())On current main, the response is accepted and the output is:
Expected behavior
A response that violates the declared response_type should be validated consistently with the graph workflow runtime: valid values may be coerced according to the existing workflow typing rules, while incompatible values should raise a clear type-mismatch error before the workflow produces output.
Impact
A malformed or incorrectly deserialized HITL response can silently enter a functional workflow as the wrong Python type. This makes the declared response_type ineffective and can produce incorrect downstream decisions, formatting, or persistence without an error at the response boundary.
Related context
The review discussion on the original functional workflow implementation in #4238 identified that response-only resumes accept responses without the type/request validation enforced by the existing workflow runtime. This issue tracks that unresolved follow-up. It is separate from #8299, which concerns user state being lost during the same response-only resume path, and from #8292, which concerns concurrent cached-step result ordering.
Summary
Functional workflows accept a response whose runtime type does not match the
response_typedeclared inRunContext.request_info()during response-only HITL resume.Reproduction
On current
main, the response is accepted and the output is:Expected behavior
A response that violates the declared
response_typeshould be validated consistently with the graph workflow runtime: valid values may be coerced according to the existing workflow typing rules, while incompatible values should raise a clear type-mismatch error before the workflow produces output.Impact
A malformed or incorrectly deserialized HITL response can silently enter a functional workflow as the wrong Python type. This makes the declared
response_typeineffective and can produce incorrect downstream decisions, formatting, or persistence without an error at the response boundary.Related context
The review discussion on the original functional workflow implementation in #4238 identified that response-only resumes accept responses without the type/request validation enforced by the existing workflow runtime. This issue tracks that unresolved follow-up. It is separate from #8299, which concerns user state being lost during the same response-only resume path, and from #8292, which concerns concurrent cached-step result ordering.