Java SDK: answer TaskHandlerParseRequest with registered handlers

[jason810496]

Stack (bottom to top), on native #74037 (stack #74170): #73973, #73974, #73975, #74317, #73976, #74067, #74135, #74140, #74141, #73971, #74030, #74031, #74032, #74136, #74137, #74138, #74139

A Java bundle now answers #73974's probe with every handler registered through @Builder.TaskHandler or Bundle.register(dagId, taskId, cls) and how its params bind, and JavaCoordinator can find and start the JAR a stub task would run. Until now a Java bundle failed on a TaskHandlerParseRequest as an unexpected first frame. Nothing calls the probe yet: #74135 does.

public static class ReportInput implements TaskInput {
  @ArgName("run_label") public String label;
  public long transformed;
}

@Builder.TaskHandler(dag = "etl", task = "transform")
public long transform(Client client, long extracted) { ... }

@Builder.TaskHandler(dag = "etl", task = "report")
public void report(ReportInput input) { ... }

answers:

TaskHandlerParsingResult(
    fileloc="/bundles/java/etl.jar",
    task_handlers={"etl": [
        TaskHandlerDeclaration(task_id="transform", binding="positional", params=[
            TaskHandlerParam(name="extracted", value_schema={"type": "integer", "format": "int64"}),
        ]),
        TaskHandlerDeclaration(task_id="report", binding="named", params=[
            TaskHandlerParam(name="run_label", exact_name=True,
                             value_schema={"anyOf": [{"type": "string"}, {"type": "null"}]}),
            TaskHandlerParam(name="transformed", value_schema={"type": "integer", "format": "int64"}),
        ]),
    ]},
)

• Only task handlers are declared. Tasks of a Dag declared in Java are left out, and Bundle.register(dagId, taskId, cls) now rejects a class generated for a @Builder.Dag task and points to @Builder.TaskHandler.
• Flat data params are positional with their Java names. A TaskInput is named, with @ArgName fields matching exactly. A handler that reads no argument is named with empty params.
• Java drops parameter names at compile time unless built with -parameters, so the annotation processor gives each generated @Builder.TaskHandler class an AIRFLOW_TASK_PARAMS field with its params' names and declared types.
• value_schema describes the declared Java type in the vocabulary build_arg_bindings emits; only primitives exclude null. It does not widen for the decoder's lenient coercions, such as "5" into a long.
• The answer is a plain map, because the generated models cannot hold task_handlers, and a test checks it against the vendored schema. The runtime waits for the parent to acknowledge it before exiting.
• The vendored supervisor schema was refreshed only by downloading a published version, and versions are published only at release, so messages added during a release cycle never reached the Java models. :sdk:syncSupervisorSchema now copies the Task SDK snapshot when it declares the configured version. It runs only when asked and the build only checks the version, so a later Task SDK schema change neither rewrites the file nor fails ktlint. This refresh also brings in main's other schema changes since the last vendoring.
• The probe checks the JAR a worker would run: _find_task_handler_artifact is the worker's own scan (main_class included) and returns the JAR that sets the Main-Class, and _build_parse_task_handler_command is a task's own command.
• The example, e2e, Scala Spark and k8s bundles registered the Java tasks of Python Dags as a Dag declared in Java, which the answer never reports. They now register them as task handlers, and runs do not change.

Compatibility: a JAR built from main's Java SDK before this change reports 2026-10-30 but cannot answer, so its probe fails and #74135 logs a warning. Rebuilding fixes it.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Claude Code (Opus 5.5) following the guidelines