The PostCommit Java ValidatesRunner ULR job is flaky

The PostCommit Java ValidatesRunner ULR is failing over 50% of the time.
Please visit https://github.com/apache/beam/actions/workflows/beam_PostCommit_Java_ValidatesRunner_ULR.yml?query=is%3Afailure+branch%3Amaster to see all failed workflow runs.
See also Grafana statistics: http://metrics.beam.apache.org/d/CTYdoxP4z/ga-post-commits-status?orgId=1&viewPanel=3&var-Workflow=PostCommit%20Java%20ValidatesRunner%20ULR

The culprit: #33385

@rohitsinha54

@rohitsinha54 ptal

Reopening since the workflow is still flaky

Stabilized

Reopened: #38497 (comment)

Does the ULR special case "javasdk" coders and now that it is a different URN that is unknown to the ULR it is presuming it is a known coder? That's a ULR bug. It should be resilient to unknown coders that have URNs.

But also can we just wipe out the Python ULR? this is a test that the Python local runner can run a Java pipeline. What we want is that the basic python runner is used for simple pipelines and the moment a pipeline is not so simple it goes to Prism.

Does the ULR special case "javasdk" coders and now that it is a different URN that is unknown to the ULR it is presuming it is a known coder? That's a ULR bug. It should be resilient to unknown coders that have URNs.

The code path is generic, happens when translating a coder from proto

  File "/runner/_work/beam/beam/sdks/python/apache_beam/runners/portability/fn_api_runner/execution.py", line 783, in _enqueue_stage_initial_inputs
    coder = self.pipeline_context.coders[self.safe_coders.get(
  File "/runner/_work/beam/beam/sdks/python/apache_beam/runners/pipeline_context.py", line 155, in __getitem__
    return self.get_by_id(id)
  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 364, in from_runner_api
    [context.coders.get_by_id(c) for c in coder_proto.component_coder_ids],
  File "/runner/_work/beam/beam/sdks/python/apache_beam/coders/coders.py", line 364, in <listcomp>
    [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 364, in from_runner_api
    [context.coders.get_by_id(c) for c in coder_proto.component_coder_ids],
  File "/runner/_work/beam/beam/sdks/python/apache_beam/coders/coders.py", line 364, in <listcomp>
    [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 364, in from_runner_api
    [context.coders.get_by_id(c) for c in coder_proto.component_coder_ids],
  File "/runner/_work/beam/beam/sdks/python/apache_beam/coders/coders.py", line 364, in <listcomp>
    [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'

Technically any runners that have Java side ended up with a schema coder then get consumed in python side could trigger the same issue?

These tests happen to expose this issue. The same test was explicitly excluded from other runners (Flink/Spark/twister2 has all excluded "UsesPerKeyOrderedDelivery"), while Python validate runner test do not have corresponding tests, persumably could also break if it does

agree with @Abacn as this isnt a ULR specific javasdk special case but it’s the generic Python proto coder path failing on beam:coder:schema:v1 because Python doesn’t register that URN yet, after Java started emitting it via ModelCoderRegistrar (#37631).

#38497 (excluding the two PerKeyOrderingTest methods in ULR) unblocks CI, but any portable Java pipeline that puts SchemaCoder in the proto and runs on the Python job service can hit the same KeyError

Fixed by #38514 in release branch

Reopening since the workflow is still flaky

For a coder that Python doesn't understand, is there a standard way that the data is just carried along as bytes?

I added some comments to #39594, but the gist is, I think I found out how to get Python to not try to create the Schema coder.

Navigation Menu

Repository navigation

The PostCommit Java ValidatesRunner ULR job is flaky #33859

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The PostCommit Java ValidatesRunner ULR job is flaky #33859

Description

Activity

Amar3tto commented on Feb 5, 2025

Amar3tto commented on Feb 5, 2025

github-actions commented on Dec 6, 2025

Amar3tto commented on Dec 8, 2025

16 remaining items

Abacn commented on May 15, 2026

kennknowles commented on May 15, 2026

kennknowles commented on May 15, 2026

Abacn commented on May 15, 2026

aIbrahiim commented on May 15, 2026

Abacn commented on May 18, 2026

github-actions commented on May 25, 2026

kennknowles commented on Aug 17, 2026

acrites commented on Aug 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions