Add Dag run context fields to the Java SDK Context

[FrankYang0529]

The Java SDK's Context only exposed dagId and runId from the Dag run, even though the supervisor already delivers the full run context in the same StartupDetails that Python tasks receive. Add fields logicalDate, dataIntervalStart / dataIntervalEnd, runAfter, ds, runType, and conf to Context.

---

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

• Yes - Claude Code with Opus 4.8

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[uranusjr]

I was partly doing this intentionally since all those context keys are quite redundant IMO. Maybe it’d be easier if we create a DagRun object (from the model in ti context, but not that type directly; similar to how Connection and Variable are bridged) to build Context with, and tell users to just use e.g. context.dagRun.runId instead?

Note that Java SDK does not need to support Jinja templating, so a top-level key in the context is not particularly useful.

[jason810496]

I was partly doing this intentionally since all those context keys are quite redundant IMO. Maybe it’d be easier if we create a DagRun object (from the model in ti context, but not that type directly; similar to how Connection and Variable are bridged) to build Context with, and tell users to just use e.g. context.dagRun.runId instead?

Isn't this PR doing exactly what the above part you mentioned?

Note that Java SDK does not need to support Jinja templating, so a top-level key in the context is not particularly useful.

Or do you mean since Java SDK does not need to support Jinja templating so we don't need to expose logicalDate, dataIntervalStart, etc, in the context?

IMO, no harm to expose those snapshotted attributes to user in the injected context.

[FrankYang0529]

I was partly doing this intentionally since all those context keys are quite redundant IMO. Maybe it’d be easier if we create a DagRun object (from the model in ti context, but not that type directly; similar to how Connection and Variable are bridged) to build Context with, and tell users to just use e.g. context.dagRun.runId instead?

Agree, I use DagRun object (context.dagRun.dataIntervalStart) rather than top-level context keys, so I think we're aligned there.

Note that Java SDK does not need to support Jinja templating, so a top-level key in the context is not particularly useful.

Yes, Java tasks have no Jinja/operator-templating path, so a task doing a backfill by data interval can only reach those through the context object.

[uranusjr]

This would drift out of sync too easily if DagRunType receives new values. Use a simple when to make the compiler check for missing items instead.

[uranusjr]

I would name this DagRunType to match the API and the Python type.

[uranusjr]

Reference the apache/airflow repo instead.