seanmuth commented on issue #71125:
URL: https://github.com/apache/airflow/issues/71125#issuecomment-5184307902

   Further data point from the same production environment (`airflow dags 
report`-style output, file paths/timings only, otherwise anonymized):
   
   ```
   File Path                                    # DAGs   # Errors   Last Runtime
   gfs-mi-reporting-4.0.jar                     0        0          74.26s
   gfs-mi-reporting-snapshot.jar                0        0          70.64s
   gfs-mi-reporting-3.5.jar                     0        0          69.63s
   gfs-mi-reporting-5.0.0.jar                   0        0          68.77s
   airflow_platform_plugins-2.11.0-py3-none-any.whl   0  0          68.45s
   nvsins_anomaly_notification_internal.py      0        1          64.00s
   providersafe_auth_user_pipeline_dag.py       0        1          63.45s
   gdds_hourly_load.py                          0        1          62.51s
   edh_data_usage_pipeline_dag.py               0        1          62.49s
   nvoei_hourly_load.py                         0        1          62.04s
   gfs-mi-reporting-4.1.jar                     0        0          62.04s
   test_dag.py                                  1        0          61.07s
   idw-edh-etl-snapshot.jar                     0        0          60.24s
   idw-edh-etl-4.0.0.jar                        0        0          11.77s
   ```
   
   Two things worth noting:
   
   1. It's not just `.jar` — a `.whl` (Python wheel, also PK-zip format) shows 
up too, confirming this affects the full family of zip-container formats from 
the original file-signature table (#45718), not just `.jar` specifically.
   2. Several *actual* `.py` DAG files with real errors are landing in the same 
60-64s band as the bogus `.jar`/`.whl` entries. I want to be careful not to 
overclaim causation here — these DAGs may simply be slow/erroring independently 
(heavy top-level code or third-party imports of their own), and this data alone 
doesn't prove the zip-format files are consuming shared processor budget from 
them. But the timing coincidence is close enough that it seems worth someone 
checking whether there's an interaction, in addition to the baseline "these 
files should never have been candidates at all."
   
   ---
   Drafted-by: Claude Code (Sonnet 5) (no human review before posting)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to