Repository navigation
[Task]: Support standard portable coder 'beam:coder:schema:v1' in all SDKs #38513
Description
What needs to happen?
The URN is introduced into Beam model in #37376 and after #37631 it started to get emitted from Java pipelines. However it's not recognized in runners written in other languages including Python:
[context.coders.get_by_id(c) for c in coder_proto.component_coder_ids],
File "/runner/_work/beam/beam/sdks/python/apache_beam/runners/pipeline_context.py", line 103, in get_by_id
self._id_to_obj[id] = self._obj_type.from_runner_api(
File "/runner/_work/beam/beam/sdks/python/apache_beam/coders/coders.py", line 361, in from_runner_api
parameter_type, constructor = cls._known_urns[coder_proto.spec.urn]
KeyError: 'beam:coder:schema:v1'
Since this is defined in Beam model, we should fix the gaps in all SDK languages
Issue Priority
Priority: 2 (default / most normal work should be filed as P2)
Issue Components
- Component: Python SDK
- Component: Java SDK
- Component: Go SDK
- Component: Typescript SDK
- Component: IO connector
- Component: Beam YAML
- Component: Beam examples
- Component: Beam playground
- Component: Beam katas
- Component: Website
- Component: Infrastructure
- Component: Spark Runner
- Component: Flink Runner
- Component: Prism Runner
- Component: Twister2 Runner
- Component: Hazelcast Jet Runner
- Component: Google Cloud Dataflow Runner
Activity
goutamadwant commentedon Aug 16, 2026
@Abacn Can you confirm the direction of this task? I reviewed the current state and related PRs. #37631 was reverted by #38516, so Java currently does not emit
beam:coder:schema:v1. The temporary test exclusions from #38497 were reverted as well.Could we keep this issue as the umbrella and split the implementation into linked tasks?
beam:coder:schema:v1test vector and refresh generated SDK bindings forSchemaCoderPayload.RowCoder, preserve the original payload, and add registry and encoding tests.For non-origin SDKs, the
to_row_fn,from_row_fn, and SDK-specific additional information should remain opaque. They should not attempt to deserialize Java function payloads. Simply converting the coder to a normal RowCoder would also be lossy because a subsequent Runner API serialization would drop the original URN and conversion metadata.I suggest treating consumption and lossless round-trip support as the first milestone. Native emission from Python, Go, and TypeScript can be separate follow-up work because that requires defining SDK-specific conversion function URNs and metadata.
If this matches the intended scope, I would be happy to start with the shared conformance case and the Python task, since Python ULR exposed the original failure.
let me know. thanks!