sending them to an upsert sink. Performance of this operator degrades exponentially in some cases.

Flink 2.2 introduces a new implementation that is optimized for such cases.

See more details about the capabilities and usages of Flink's

[Delta Joins](https://nightlies.apache.org/flink/flink-docs-release-2.2/docs/dev/table/tuning/#delta-joins).

Before Flink 2.2, row types defined in SQL e.g.`SELECT CAST(f AS ROW<i NOT NULL>)` did ignore

the`NOT NULL` constraint. This was more aligned with the SQL standard but caused many type

inconsistencies and cryptic error message when working on nested data. For example, it prevented

using rows in computed columns or join keys. The new behavior takes the nullability into consideration.

The config option`table.legacy-nested-row-nullability` allows to restore the old behavior if required,

but it is recommended to update existing queries that ignored constraints before.

Casting to TIME type now considers the correct precision (0-3). Casting incorrect strings to time

(e.g. where the hour component is higher than 24) leads to a runtime exception now. Casting between

BINARY and VARBINARY should now correctly consider the target length.

the new configuration`historyserver.archive.retained-ttl` combining with`historyserver.archive.retained-jobs`

to fulfill more scenario requirements.

Since 2.2.0 users can now assign custom metric variables for each operator/transformation used in the

Job. Those variables are later converted to tags/labels by the metric reporters, allowing users to

tab/label specific operator's metrics. For example, you can use this to name and differentiate sources.

Users can now control the level of details of checkpoint spans via[traces.checkpoint.span-detail-level](https://nightlies.apache.org/flink/flink-docs-release-2.2/docs/deployment/config/#traces-checkpoint-span-detail-level).

Highest levels report tree of spans for each task and subtask. Reported custom spans can now contain

children spans. See more details in[Traces](https://nightlies.apache.org/flink/flink-docs-release-2.2/docs/ops/traces/).

Since 2.1.0 users are able to report custom events using the EventReporters. Since 2.2.0 Flink reports

some built-in/system events.

This is considerable optimization and an breaking change for the StreamingMultiJoinOperator.

As noted in the release notes, the operator was launched in an experimental state for Flink 2.1

since we're working on relevant optimizations that could be breaking changes.

Upgrade org.apache.commons:commons-lang3 from 3.12.0 to 3.18.0 to mitigateCVE-2025-48924.

Flink now uses protobuf-java 4.32.1 (corresponding to Protocol Buffers version 32), upgrading from

protobuf-java 3.21.7 (Protocol Buffers version 21). This major upgrade enables:

-**Protobuf Editions Support**: Full support for the new`edition = "2023"` and`edition = "2024"`

syntax introduced in Protocol Buffers v27+. Editions provide a unified approach that combines

proto2 and proto3 functionality with fine-grained feature control.

-**Improved Proto3 Field Presence**: Better handling of optional fields in proto3 without the

limitations of older protobuf versions, eliminating the need to set`protobuf.read-default-values`

to`true` for field presence checking.

-**Enhanced Performance**: Leverages performance improvements and bug fixes from 11 Protocol

Buffers releases (versions 22-32).

-**Modern Protobuf Features**: Access to newer protobuf capabilities including Edition 2024

features and improved runtime behavior.

Users with existing proto2 and proto3`.proto` files will continue to work without changes.

sending them to an upsert sink. Performance of this operator degrades exponentially in some cases.

Flink 2.2 introduces a new implementation that is optimized for such cases.

In 2.1, Apache Flink has introduced a new delta join operator to mitigate the challenges caused by

big state in regular joins. It replaces the large state maintained by regular joins with a

In 2.1, Apache Flink has introduced a new delta join operator to mitigate the challenges caused by

big state in regular joins. It replaces the large state maintained by regular joins with a

bidirectional lookup-based join that directly reuses data from the source tables.

Flink 2.2 enhances support for converting more SQL patterns into delta joins. Delta joins now

support consuming CDC sources without DELETE operations, and allow projection and filter operations

after the source. Additionally, delta joins include support for caching, which helps reduce requests

Flink 2.2 enhances support for converting more SQL patterns into delta joins. Delta joins now

support consuming CDC sources without DELETE operations, and allow projection and filter operations

after the source. Additionally, delta joins include support for caching, which helps reduce requests

to external storage.

See more details about the capabilities and usages of Flink's

See more details about the capabilities and usages of Flink's

[Delta Joins](https://nightlies.apache.org/flink/flink-docs-release-2.2/docs/dev/table/tuning/#delta-joins).

Before Flink 2.2, row types defined in SQL e.g.`SELECT CAST(f AS ROW<i NOT NULL>)` did ignore

the`NOT NULL` constraint. This was more aligned with the SQL standard but caused many type

inconsistencies and cryptic error message when working on nested data. For example, it prevented

using rows in computed columns or join keys. The new behavior takes the nullability into consideration.

The config option`table.legacy-nested-row-nullability` allows to restore the old behavior if required,

but it is recommended to update existing queries that ignored constraints before.

Casting to TIME type now considers the correct precision (0-3). Casting incorrect strings to time

(e.g. where the hour component is higher than 24) leads to a runtime exception now. Casting between

BINARY and VARBINARY should now correctly consider the target length.

the new configuration`historyserver.archive.retained-ttl` combining with`historyserver.archive.retained-jobs`

to fulfill more scenario requirements.

Since 2.2.0 users can now assign custom metric variables for each operator/transformation used in the

Job. Those variables are later converted to tags/labels by the metric reporters, allowing users to

tab/label specific operator's metrics. For example, you can use this to name and differentiate sources.

Users can now control the level of details of checkpoint spans via[traces.checkpoint.span-detail-level](https://nightlies.apache.org/flink/flink-docs-release-2.2/docs/deployment/config/#traces-checkpoint-span-detail-level).

Highest levels report tree of spans for each task and subtask. Reported custom spans can now contain

children spans. See more details in[Traces](https://nightlies.apache.org/flink/flink-docs-release-2.2/docs/ops/traces/).

Since 2.1.0 users are able to report custom events using the EventReporters. Since 2.2.0 Flink reports

some built-in/system events.

This is considerable optimization and an breaking change for the StreamingMultiJoinOperator.

As noted in the release notes, the operator was launched in an experimental state for Flink 2.1

since we're working on relevant optimizations that could be breaking changes.

In Flink 2.2, we have added support of async function in Python DataStream API. This enables Python

users to efficiently query external services in their Flink jobs, e.g. large-sized LLM which is

In Flink 2.2, we have added support of async function in Python DataStream API. This enables Python

users to efficiently query external services in their Flink jobs, e.g. large-sized LLM which is

typically deployed in a standalone GPU cluster, etc.

Furthermore, we have provided comprehensive support to ensure the stability of external service

access. On one hand, we support limiting the number of concurrent requests sent to the external

service to avoid overwhelming it. On the other hand, we have also added retry support to tolerate

Furthermore, we have provided comprehensive support to ensure the stability of external service

access. On one hand, we support limiting the number of concurrent requests sent to the external

service to avoid overwhelming it. On the other hand, we have also added retry support to tolerate

temporary unavailability which maybe caused by network jitter or other transient issues.

Upgrade org.apache.commons:commons-lang3 from 3.12.0 to 3.18.0 to mitigateCVE-2025-48924.

Flink now uses protobuf-java 4.32.1 (corresponding to Protocol Buffers version 32), upgrading from

protobuf-java 3.21.7 (Protocol Buffers version 21). This major upgrade enables:

-**Protobuf Editions Support**: Full support for the new`edition = "2023"` and`edition = "2024"`

syntax introduced in Protocol Buffers v27+. Editions provide a unified approach that combines

proto2 and proto3 functionality with fine-grained feature control.

-**Improved Proto3 Field Presence**: Better handling of optional fields in proto3 without the

limitations of older protobuf versions, eliminating the need to set`protobuf.read-default-values`

to`true` for field presence checking.

-**Enhanced Performance**: Leverages performance improvements and bug fixes from 11 Protocol

Buffers releases (versions 22-32).

-**Modern Protobuf Features**: Access to newer protobuf capabilities including Edition 2024

features and improved runtime behavior.

Users with existing proto2 and proto3`.proto` files will continue to work without changes.