Add support for pandas 3 based xcoms in airflow - #71103
Conversation
pandas 3 exposes its public classes from the `pandas` namespace, so a DataFrame is now qualified as `pandas.DataFrame` rather than `pandas.core.frame.DataFrame`. The serializer was registered only under the old name, so pushing a DataFrame through XCom raised "cannot serialize object of type <class 'pandas.DataFrame'>". Both names are registered so values written by either version stay readable. pandas 3 also infers a str column where it used to infer object, and keeps its missing values as NA instead of stringifying them, which the amazon and salesforce tests asserted on.
Deployments need to know that every component has to carry the pandas 3 support before pandas 3 reaches any worker, that a rollback strands the XComs written in the meantime, and that a pulled DataFrame now takes its dtypes from the reader's pandas version.
|
Ah I have to resolve conflicts |
b6ba25b to
c90765a
Compare
|
Compat failures are unrelated, likely fixed by #71145. I will review that |
|
Failures fixed by #71145, merging this one. |
Backport failed to create: v3-3-test. View the failure log Run detailsNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
You can attempt to backport this manually by running: cherry_picker 4091ccf v3-3-testThis should apply the commit to the v3-3-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continueIf you don't have cherry-picker installed, see the installation guide. |
Backport of #71100, which reverted "Limit pandas to < 3 for DataFrame XComs" (#70791) on main. v3-3-test carried the cap via the #70912 backport; reverting that commit removes the cap here too so the release branch matches main. The pandas-3 XCom serializer support lands separately in #71169 (the #71103 backport) -- the same order main used (#71100 before #71103). uv.lock regenerated with uv 0.12.1 to drop the pandas <3 specifier.
* Keep DataFrame XComs working on pandas 3 pandas 3 exposes its public classes from the `pandas` namespace, so a DataFrame is now qualified as `pandas.DataFrame` rather than `pandas.core.frame.DataFrame`. The serializer was registered only under the old name, so pushing a DataFrame through XCom raised "cannot serialize object of type <class 'pandas.DataFrame'>". Both names are registered so values written by either version stay readable. pandas 3 also infers a str column where it used to infer object, and keeps its missing values as NA instead of stringifying them, which the amazon and salesforce tests asserted on. * Document pandas 3 impact on DataFrame XComs Deployments need to know that every component has to carry the pandas 3 support before pandas 3 reaches any worker, that a rollback strands the XComs written in the meantime, and that a pulled DataFrame now takes its dtypes from the reader's pandas version. * Name the pandas 3 newsfragment after its own pull request * Add regression test for the pandas 2/3 cross-version registry lookup * rename newsfragment file --------- Co-authored-by: Jarek Potiuk <jarek@potiuk.com> (cherry picked from commit 4091ccf)
* Keep DataFrame XComs working on pandas 3 pandas 3 exposes its public classes from the `pandas` namespace, so a DataFrame is now qualified as `pandas.DataFrame` rather than `pandas.core.frame.DataFrame`. The serializer was registered only under the old name, so pushing a DataFrame through XCom raised "cannot serialize object of type <class 'pandas.DataFrame'>". Both names are registered so values written by either version stay readable. pandas 3 also infers a str column where it used to infer object, and keeps its missing values as NA instead of stringifying them, which the amazon and salesforce tests asserted on. * Document pandas 3 impact on DataFrame XComs Deployments need to know that every component has to carry the pandas 3 support before pandas 3 reaches any worker, that a rollback strands the XComs written in the meantime, and that a pulled DataFrame now takes its dtypes from the reader's pandas version. * Name the pandas 3 newsfragment after its own pull request * Add regression test for the pandas 2/3 cross-version registry lookup * rename newsfragment file --------- (cherry picked from commit 4091ccf) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
Backport of #71100, which reverted "Limit pandas to < 3 for DataFrame XComs" (#70791) on main. v3-3-test carried the cap via the #70912 backport; reverting that commit removes the cap here too so the release branch matches main. The pandas-3 XCom serializer support lands separately in #71169 (the #71103 backport) -- the same order main used (#71100 before #71103). uv.lock regenerated with uv 0.12.1 to drop the pandas <3 specifier.
* Keep DataFrame XComs working on pandas 3 pandas 3 exposes its public classes from the `pandas` namespace, so a DataFrame is now qualified as `pandas.DataFrame` rather than `pandas.core.frame.DataFrame`. The serializer was registered only under the old name, so pushing a DataFrame through XCom raised "cannot serialize object of type <class 'pandas.DataFrame'>". Both names are registered so values written by either version stay readable. pandas 3 also infers a str column where it used to infer object, and keeps its missing values as NA instead of stringifying them, which the amazon and salesforce tests asserted on. * Document pandas 3 impact on DataFrame XComs Deployments need to know that every component has to carry the pandas 3 support before pandas 3 reaches any worker, that a rollback strands the XComs written in the meantime, and that a pulled DataFrame now takes its dtypes from the reader's pandas version. * Name the pandas 3 newsfragment after its own pull request * Add regression test for the pandas 2/3 cross-version registry lookup * rename newsfragment file --------- (cherry picked from commit 4091ccf) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
Was generative AI tooling used to co-author this PR?
Supersedes #70558
Following discussion from Ash on https://lists.apache.org/thread/tbv4q04b3xx1hnmtq1b34tkzf43d5yqz
pandas 3 exposes its public classes from the
pandasnamespace, so a DataFrame is qualified aspandas.DataFramerather thanpandas.core.frame.DataFrame. The serde registry is keyed on thatname and only knew the old one, so under pandas 3 no DataFrame could be pushed through XCom at
all:
Both names are now registered, so a DataFrame written by either pandas version can be read by
either. Verified across all four combinations (writer x reader), with the payload written by one
interpreter and read by the other:
object, missing =Noneobject, missing =Nonestr, missing =nanstr, missing =nanThe reader's pandas version decides the dtypes, not the writer's -- that, and the fact that a
component without this change cannot read a pandas-3-written DataFrame XCom, is what the
significant newsfragment documents.
Two provider tests also asserted on pandas 2 behaviour (
objectdtype, missing values stringifiedto
"nan"/"None") and are now version-aware. The production paths were already correct.Reopened from #70558 -- carries the same three commits unchanged, plus one added test closing a
review gap: nothing previously forced deserialization through the registry entry for the other
pandas major's qualname, since
serialize()only ever produces the qualname of whatever pandas isactually installed. Depends on the separate revert of #70791 landing first.
related: #70558, #70791
Testing
Testing with pandas v2
DAG:
Testing with pandas v3
{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.