Skip to content

Add transfer type converters - #3073

Open
VegetarianOrc wants to merge 17 commits into
mainfrom
amazzeo/transfer-type-converters
Open

VegetarianOrc wants to merge 17 commits into
mainfrom
amazzeo/transfer-type-converters

Conversation

@VegetarianOrc

Copy link
Copy Markdown
Contributor

What changed?

  • Adds experimental @TransferTypeConvertible and TransferTypeConverter APIs for converting top-level model values to a transfer representation before data conversion.
  • Applies transfer conversion across workflow, activity, Nexus, schedule, test activity environment, and workflow stream paths.
  • Adds workflow-stream item conversion support, documentation, and coverage for converter behavior, codecs, and SDK integration points.

Why?

  • Lets applications define a model-owned transfer representation while retaining the configured data converter for payload serialization, codecs, and wire encoding.

Breaking changes?

  • No.

Server PR

  • No.

@VegetarianOrc
VegetarianOrc marked this pull request as ready for review September 15, 2026 16:44
@VegetarianOrc
VegetarianOrc requested review from a team as code owners September 15, 2026 16:44
// Set merged plugins after configuration, then build
builder.setPlugins(mergedPlugins);
options = builder.build();
options =

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why build the options then immediately call ScheduleClientOptions.newBuilder(options)?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a pass at cleaning this up a little by passing the data converter into the invoker rather than pulling it from the options. Not 100% sure that's a reasonable approach so happy to consider a better alternative here if there is one.

@Quinn-With-Two-Ns

Copy link
Copy Markdown
Contributor

We took a very different approach to wrapping the users DataConverter here vs externalStorage especially for client calls, was there a reason we needed to diverge I would kind of expect both to have the same requirements ?

Pass transfer-aware converters to Activity and Schedule invokers without rebuilding their configured options. Preserve serialization context for task-token heartbeats and propagate the configured converter to test Nexus clients.
@VegetarianOrc

Copy link
Copy Markdown
Contributor Author

We took a very different approach to wrapping the users DataConverter here vs externalStorage especially for client calls, was there a reason we needed to diverge I would kind of expect both to have the same requirements ?

Thanks for calling this out. I've taken a pass to consolidate the client side converter creation into ClientDataConverterFactory (renamed from WorkflowClientDataConverterFactory). I think it's closer to what you had in mind, but let me know if I'm off.

I've left the worker side separate for now since the transfer type conversion happens in a workflow thread but the external storage must remain separate on that side. There may still be cleanup possible that I can explore if you think it could use some attention.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants