Codingaditya17 commented on issue #67515:
URL: https://github.com/apache/airflow/issues/67515#issuecomment-4539523292

   Thanks for the clarification. That makes sense, especially breaking this up 
provider by provider so each PR stays small and can be reviewed and tested in 
the context of that specific provider.
   
   I opened a focused PR for the Elasticsearch provider here: 
https://github.com/apache/airflow/pull/67519
   
   For this first provider-specific PR, I followed the pattern described above. 
I moved the `Elasticsearch` client import out of the module-level imports, kept 
it under `TYPE_CHECKING` for type annotations, moved the runtime import into 
the places where the Elasticsearch client is actually created, and updated the 
affected unit-test mock since `Elasticsearch` is no longer exposed as a 
module-level symbol in the hook module.
   
   I started with Elasticsearch because it is one of the providers listed in 
the report, and the change surface looked small enough for a first focused PR.
   
   Local validation completed:
   
   `uv run pytest 
providers/elasticsearch/tests/unit/elasticsearch/hooks/test_elasticsearch.py 
-q`  
   Result: `26 passed, 1 warning`
   
   `uv run pytest providers/elasticsearch/tests/unit/elasticsearch -q`  
   Result: `131 passed, 1 warning`
   
   `uv run prek run --files 
providers/elasticsearch/src/airflow/providers/elasticsearch/hooks/elasticsearch.py
 providers/elasticsearch/tests/unit/elasticsearch/hooks/test_elasticsearch.py`  
   Result: passed
   
   I have not added before/after performance numbers yet. If that is expected 
for each provider-specific PR, I can run the profiling script locally and add 
the results to the PR description.


-- 
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