Repository navigation
[WORKFLOW SDK FEATURE REQUEST] Support pydantic models #858
Description
Describe the WORKFLOW SDK feature
It would be convenient if workflows/activities could support Pydantic models as input, automatically handling the (de)serializaiton. Right now, they only support dictionaries or simple values. The motivation comes from wanting to use strongly typed objects vs dictionaries (which are more opaque in their types).
There is some precedent here with the FastAPI extension supporting them in subscriptions.
acceptance criteria:
- workflows/activities use pydantic models as their inputs
- we still support dictionaries and can serialize dictionaries into pydantic models
- dapr quickstarts are all updated
- dapr docs are all updated
Release Note
RELEASE NOTE: feat: workflows and activities support Pydantic models as their inputs
Reacted by Oliver Tomlinson
Activity
acroca commentedon Oct 30, 2025
Thank you for opening the issue!
I checked the Go and Java SDKs and they both support custom user objects, using JSON. But both Go and Java have an 'easy' way to support this out of the box, so it doesn't add a lot of complexity.
I'm wondering if it'd be possible to support any sort of object that is serializable and deserializable using json, to add a more generic support to json->object instead of just pydantic. Any thoughts?
Also, we need to make sure the
pydanticdependency is optional.leechristensen commentedon Oct 30, 2025
Swappable serializers I'm sure would be welcome! I think adding a serializer arg to the
subscribemethod would be a good option, or expose a way to set that globally all across all subscribers.Is it necessary to restrict to JSON? I personally use Pydantic JSON objects the most, but Protobufs/Grpc are a close 2nd. Dapr uses Protobufs underneath IIRC so I feel like it slots in well there.
My preference would be to use Python extras to install the functionality. That way users could do something like:
But that does deviate away from how some of the current sdk extensions are implemented (i.e. as other pypi packages)
olitomlinson commentedon Dec 24, 2025
Big +1 for supporting Pydantic models and alternative serializers. Having consistency across the SDK is essential for good UX (and the precedent has already been set, so unless there is a good reason not to we should do this)
dapr-bot commentedon Mar 24, 2026
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
olitomlinson commentedon Apr 16, 2026
@sicoyle @acroca I think the priority of this needs reconsidering.
Folks will expect good Pydantic support out of the box. I find that I have to drop down to passing around
dictsto get a good level of interoperability for cross-app workflows, which, is not great.Which leaves the code in an undesirable state... which isn't a joy to author for any one considering Dapr Workflows.