The GitHub Actions job "Tests (AMD)" on 
airflow.git/feature/java-sdk-arg-bindings-runtime has failed.
Run started by GitHub user jason810496 (triggered by jason810496).

Head commit for run:
9e7cab73e8f0a6acb2fa5ce95ac0ab46bdb7b9cc / LIU ZHE YOU <[email protected]>
Java SDK: Honor TaskFlow arg bindings sent by the supervisor

For a stub-backed Dag the Python file's `@task.stub` call site is the graph
the scheduler actually orders the run by, so it must also be what feeds the
Java task its inputs. The Java side previously re-declared that data flow
with `@Builder.XCom(task = "...")`, duplicating the Dag file's wiring in a
second place that nothing keeps honest: rename or re-wire a task in Python
and the Java annotation silently keeps pulling the old upstream. The
2026-10-30 supervisor schema delivers the call site's bindings with every
task run, so the runtime can read them instead of guessing.

Binding is positional, matching the Go SDK's flat-parameter contract: Java
parameter names are not API, so an IDE rename must never rebind an input.
Keyword-style calls bind by name only through an explicit `TaskInput` bundle
whose public fields declare their wire names -- the deliberate, tagged
boundary for snake_case-to-camelCase crossings. A task declares flat data
parameters or one bundle, never both, so field names and positions cannot
shift each other.

jsonSchema2Pojo cannot express the kind-discriminated binding union, so the
generated `TIRunContext` carries the raw payload and a small hand-written
decoder materializes the typed view.

Report URL: https://github.com/apache/airflow/actions/runs/31021685270

With regards,
GitHub Actions via GitBox


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to