Under which category would you file this issue?
Airflow Core
Apache Airflow version
3.2.2
What happened and how to reproduce it?
Issue description
An exponent-form JSON number in DagRun.conf changes representation and Python type after Airflow persists and reads the configuration through PostgreSQL JSONB.
For example:
is stored by PostgreSQL JSONB in canonical expanded numeric form. When Airflow reads the configuration back, the value is a 309-digit Python int rather than the original finite Python float. This changes the task input before the task body runs.
It can also produce an integer outside MessagePack's range and trigger the separate transport failure tracked in #73712. The proposed transport fallback for that issue preserves the oversized integer but does not address this earlier number conversion.
Steps to reproduce
-
Run Airflow 3.2.2 with PostgreSQL and CeleryExecutor.
-
Trigger a DAG with this configuration:
-
Inspect the value inside a task:
value = context["dag_run"].conf["value"]
print(type(value), value)
-
Observe that the retrieved value is a 309-digit Python int, not a float.
The PostgreSQL transformation can also be seen independently:
SELECT '{"value": 1.7E308}'::jsonb;PostgreSQL returns the number in expanded canonical form. Subsequent JSON deserialization interprets that integral token as a Python int.
What you think should happen instead?
DagRun.conf should preserve the submitted JSON number semantics across persistence and task startup. An exponent-form finite number should not unexpectedly become a very large Python integer.
If exact representation cannot be preserved with the current JSONB mapping, Airflow should document and validate this boundary or retain an opaque/original serialized form for task transport.
Operating System
No response
Deployment
Official Apache Airflow Helm Chart
Apache Airflow Provider(s)
No response
Versions of Apache Airflow Providers
apache-airflow-providers-celery
Official Helm Chart version
Not Applicable
Kubernetes Version
No response
Helm Chart configuration
Not Applicable
Docker Image customizations
Not Applicable
Anything else?
Related: #73712 tracks failure to transport the resulting oversized integer through MessagePack. This issue is specifically about the earlier JSON-number representation and Python-type change.
Are you willing to submit PR?
Code of Conduct
Under which category would you file this issue?
Airflow Core
Apache Airflow version
3.2.2
What happened and how to reproduce it?
Issue description
An exponent-form JSON number in
DagRun.confchanges representation and Python type after Airflow persists and reads the configuration through PostgreSQL JSONB.For example:
{"value": 1.7E308}is stored by PostgreSQL JSONB in canonical expanded numeric form. When Airflow reads the configuration back, the value is a 309-digit Python
intrather than the original finite Pythonfloat. This changes the task input before the task body runs.It can also produce an integer outside MessagePack's range and trigger the separate transport failure tracked in #73712. The proposed transport fallback for that issue preserves the oversized integer but does not address this earlier number conversion.
Steps to reproduce
Run Airflow 3.2.2 with PostgreSQL and CeleryExecutor.
Trigger a DAG with this configuration:
{"value": 1.7E308}Inspect the value inside a task:
Observe that the retrieved value is a 309-digit Python
int, not afloat.The PostgreSQL transformation can also be seen independently:
PostgreSQL returns the number in expanded canonical form. Subsequent JSON deserialization interprets that integral token as a Python
int.What you think should happen instead?
DagRun.confshould preserve the submitted JSON number semantics across persistence and task startup. An exponent-form finite number should not unexpectedly become a very large Python integer.If exact representation cannot be preserved with the current JSONB mapping, Airflow should document and validate this boundary or retain an opaque/original serialized form for task transport.
Operating System
No response
Deployment
Official Apache Airflow Helm Chart
Apache Airflow Provider(s)
No response
Versions of Apache Airflow Providers
apache-airflow-providers-celery
Official Helm Chart version
Not Applicable
Kubernetes Version
No response
Helm Chart configuration
Not Applicable
Docker Image customizations
Not Applicable
Anything else?
Related: #73712 tracks failure to transport the resulting oversized integer through MessagePack. This issue is specifically about the earlier JSON-number representation and Python-type change.
Are you willing to submit PR?
Code of Conduct