Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-24 Thread via GitHub


shahar1 closed issue #61766: Status of testing Providers that were prepared on 
February 10, 2026
URL: https://github.com/apache/airflow/issues/61766


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-23 Thread via GitHub


wilsonhooi86 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3944723408

   > All my changes look good!
   
   Hi @henry3260 , thank you so much for completing this PR for 
GlueJobOperator. However, I think it is not working from my end. I created an 
issue for your reference: https://github.com/apache/airflow/issues/62353


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-16 Thread via GitHub


csp33 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3909442365

   I think I found a bug in the fab provider
   https://github.com/apache/airflow/issues/62028


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-14 Thread via GitHub


potiuk commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3902017577

   I created an issue for that https://github.com/apache/airflow/issues/61913 


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-14 Thread via GitHub


potiuk commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3902002494

   @shahar1 @vincbeck @o-nikolas  -> just a small warning. Seems that celery 
provider caused problems when I run tests for 2.11.1
   
   ```python
   Traceback (most recent call last):
   File 
"/home/airflow/.local/lib/python3.10/site-packages/airflow/jobs/scheduler_job_runner.py",
 line 1008, in _execute
 self._run_scheduler_loop()
   File 
"/home/airflow/.local/lib/python3.10/site-packages/airflow/jobs/scheduler_job_runner.py",
 line 1153, in _run_scheduler_loop
 executor.heartbeat()
   File 
"/home/airflow/.local/lib/python3.10/site-packages/airflow/traces/tracer.py", 
line 58, in wrapper
 return func(*args, **kwargs)
   File 
"/home/airflow/.local/lib/python3.10/site-packages/airflow/executors/base_executor.py",
 line 244, in heartbeat
 self.trigger_tasks(open_slots)
   File 
"/home/airflow/.local/lib/python3.10/site-packages/airflow/traces/tracer.py", 
line 58, in wrapper
 return func(*args, **kwargs)
   File 
"/home/airflow/.local/lib/python3.10/site-packages/airflow/executors/base_executor.py",
 line 383, in trigger_tasks
 self._process_tasks(task_tuples)
   File 
"/home/airflow/.local/lib/python3.10/site-packages/airflow/providers/celery/executors/celery_executor.py",
 line 150, in _process_tasks
 task_tuples_to_send = [task_tuple[:3] + (self.team_name,) for 
task_tuple in task_tuples]
   File 
"/home/airflow/.local/lib/python3.10/site-packages/airflow/providers/celery/executors/celery_executor.py",
 line 150, in 
 task_tuples_to_send = [task_tuple[:3] + (self.team_name,) for 
task_tuple in task_tuples]
 AttributeError: 'CeleryExecutor' object has no attribute 'team_name'
   ```
   
   See 
https://github.com/apache/airflow/actions/runs/22018420629/job/63624588757?pr=61909
 - this one contains the latest celary provider released and it might need some 
follow-up release. 
   
   I do not think we need to something **quick** for it, I will exclude 3.16.0 
celery provider from airflow 2.11.1 build but we will have to fix it for 2.11 
compatibility. Probably we did not have enough unit tests to cover it - only 
Docker compose tests in 2.11.1 detected it.


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-13 Thread via GitHub


shahar1 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3901276939

   > It looks like [#61441](https://github.com/apache/airflow/pull/61441) broke 
EKS operators with an api version mismatch. 
[#61891](https://github.com/apache/airflow/pull/61891) should be the two-line 
fix. Is there any chance we can squeeze 61891 in this release, or drop 61441 
from this release?
   
   Unfortunately, there's no practical way* in the release procedure to drop 
specific commits from the release or squeeze changes into it, so I'll just 
exclude it from the upcoming release and release it with the fix in RC2 
(hopefully during this week). 
   
   
   \*If we make any changes to source code during the release process, we need 
to run the both the technical procedure and PMC votes all over again


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-13 Thread via GitHub


ferruzzi commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3900069491

   It looks like https://github.com/apache/airflow/pull/61441 broke EKS 
operators with an api version mismatch.  
https://github.com/apache/airflow/pull/61891 should be the two-line fix.  Is 
there any chance we can squeeze 61891 in this release, or drop 61441 from this 
release?


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-13 Thread via GitHub


vaefremov95 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-398582

   @shahar1 
   > Thanks for the detailed info! If it happens regardless of the new feature 
(which means that it also happens in older versions), and you're not able to 
fix it in the next few days - then please create an issue and I'll release it 
as-is. If it's a regression due to the new parameter, or you're able to fix it 
fast - I prefer to postpone the release until it's fixed.
   > 
   > Please let me know ASAP, the vote ends in less than 10 hours (if you don't 
update by then, I'll release it). Thanks again!
   
   Tested with airflow 2.11 and apache-airflow-providers-imap==3.10.3. 
   There are 3 emails with same files. Downloading only 1 .
   ```
   [2026-02-13, 22:43:03 UTC] {imap.py:336} INFO - Found attachment: test.xlsx
   [2026-02-13, 22:43:03 UTC] {imap.py:336} INFO - Found attachment: test.xlsx
   [2026-02-13, 22:43:03 UTC] {imap.py:336} INFO - Found attachment: test.xlsx
   [2026-02-13, 22:43:03 UTC] {logging_mixin.py:190} INFO - downloaded 
attachments without max_mails: 1
   ```
   
   https://github.com/user-attachments/assets/50a88dce-b532-4767-b23d-753989cc1262";
 />
   
   Same picturewith airflow 2.10.5 and apache-airflow-providers-imap==3.8.0. 
   
   So i guess this is default behavior for older versions. 
   I wont be able to fix this in the next few days and will create an issue.
   


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-13 Thread via GitHub


shahar1 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3899855176

   > HI! I have tested new feature **max_mails** added in PR 
[#60963](https://github.com/apache/airflow/pull/60963) with my test Airflow 
Deployment (Airflow==2.11. Python 3.12.3). I used my company's production IMAP 
server and real-case scenario. I have 3 emails returned by filter, each with 2 
attachments, but I needed to retrieve only last mail. I tested methods 
_has_mail_attachment_, _retrieve_mail_attachments_, and 
_download_mail_attachments_ with different settings for max_mails. Here are 
some logs:
   > 
   > ```
   > [2026-02-13, 20:50:34 UTC] {logging_mixin.py:190} INFO - attachemnts found 
with max_mails: True
   > [2026-02-13, 20:50:34 UTC] {logging_mixin.py:190} INFO - count attachments 
without max_mails: 6
   > [2026-02-13, 20:50:34 UTC] {logging_mixin.py:190} INFO - count attachments 
with max_mails=1: 2
   > [2026-02-13, 20:50:34 UTC] {logging_mixin.py:190} INFO - count attachments 
with max_mails=1 and latest_only: 1
   > [2026-02-13, 20:50:38 UTC] {logging_mixin.py:190} INFO - downloaded 
attachments without max_mails: 4
   > [2026-02-13, 20:50:39 UTC] {logging_mixin.py:190} INFO - downloaded 
attachments with max_mails=1: 2
   > [2026-02-13, 20:50:40 UTC] {logging_mixin.py:190} INFO - downloaded 
attachments with max_mails=1 and latest_only: 1
   > ```
   > 
   > Everything works as expected, exept one detail. Since some files have same 
names, _download_mail_attachments_ method overwrites them. So instead of 6 
files I get 4. I guess that this is the default behavior of this method, that 
occurs regardless of new feature **max_mails** but nevertheless it should be 
fixed. I will make additional research on this problem and will create an issue 
if my suspicions are correct
   
   Thanks for the detailed info! 
   If it happens regardless of the new feature (which means that it also 
happens in older versions), and you're not able to fix it in the next few days 
- then please create an issue and I'll release it as-is.
   If it's a regression due to the new parameter, or you're able to fix it fast 
- I prefer to postpone the release until it's fixed.
   
   Please let me know ASAP, the vote ends in less than 10 hours (if you don't 
update by then, I'll release it).
   Thank you!


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-13 Thread via GitHub


vaefremov95 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3899633514

   HI!
   I have tested new feature **max_mails**  added in PR #60963 with my test 
Airflow Deployment (Airflow==2.11. Python 3.12.3).
   I used my company's production IMAP server and real-case scenario. I have 3 
emails returned by filter, each with 2 attachments, but I needed to retrieve 
only last mail.
   I tested methods _has_mail_attachment_, _retrieve_mail_attachments_, and 
_download_mail_attachments_ with different settings for max_mails.
   Here are some logs:
   ```
   [2026-02-13, 20:50:34 UTC] {logging_mixin.py:190} INFO - attachemnts found 
with max_mails: True
   [2026-02-13, 20:50:34 UTC] {logging_mixin.py:190} INFO - count attachments 
without max_mails: 6
   [2026-02-13, 20:50:34 UTC] {logging_mixin.py:190} INFO - count attachments 
with max_mails=1: 2
   [2026-02-13, 20:50:34 UTC] {logging_mixin.py:190} INFO - count attachments 
with max_mails=1 and latest_only: 1
   [2026-02-13, 20:50:38 UTC] {logging_mixin.py:190} INFO - downloaded 
attachments without max_mails: 4
   [2026-02-13, 20:50:39 UTC] {logging_mixin.py:190} INFO - downloaded 
attachments with max_mails=1: 2
   [2026-02-13, 20:50:40 UTC] {logging_mixin.py:190} INFO - downloaded 
attachments with max_mails=1 and latest_only: 1
   ```
   Everything works as expected, exept one detail. Since some files have same 
names, _download_mail_attachments_ method overwrites them. So instead of 6 
files I get 4. I guess that this is the default behavior of this method, that 
occurs regardless of new feature **max_mails** but nevertheless it should be 
fixed. 
   


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-12 Thread via GitHub


shahar1 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3891826110

   Thanks @VladaZakharova and @gustavosaquino !
   I'll exclude Google and Azure from upcoming release.
   
   CC: @dabla 


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-12 Thread via GitHub


gustavosaquino commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3891320866

   Tested PR #60369 and not OK
   
   The default behavior of PowerBIDatasetRefreshOperator in version 12.9.0 is 
to wait for the dataset update status. When running the same DAG with version 
13.0.0rc1, this default behavior is changed to trigger the update and not wait 
for the response, and there is a warning in the logs about the new 
wait_for_completion parameter.
   
   `WARNING - The PowerBIDatasetRefreshOperator now always uses deferrable 
execution when wait_for_completion=True.`
   
   When setting the parameter in the DAG to True, the operator does not wait 
for the dataset update status, and when set to False, it displays an execution 
error as shown below:
   
   ```
   [2026-02-12T14:23:52.261194Z] INFO - Triggered dataset refresh  (fire-and-forget)
   [2026-02-12T14:23:52.261475Z] ERROR - Task failed with exceptionTypeError: 
cannot serialize object of type 
   File 
/home/airflow/.local/lib/python3.12/site-packages/airflow/sdk/execution_time/task_runner.py,
 line 1068 in run
   File 
/home/airflow/.local/lib/python3.12/site-packages/airflow/sdk/execution_time/task_runner.py,
 line 1477 in _execute_task
   File 
/home/airflow/.local/lib/python3.12/site-packages/airflow/sdk/bases/operator.py,
 line 417 in wrapper
   File 
/home/airflow/.local/lib/python3.12/site-packages/airflow/providers/microsoft/azure/operators/powerbi.py,
 line 134 in execute
   File 
/home/airflow/.local/lib/python3.12/site-packages/airflow/sdk/execution_time/task_runner.py,
 line 421 in xcom_push
   File 
/home/airflow/.local/lib/python3.12/site-packages/airflow/sdk/execution_time/task_runner.py,
 line 588 in _xcom_push
   File 
/home/airflow/.local/lib/python3.12/site-packages/airflow/sdk/bases/xcom.py, 
line 77 in set
   File 
/home/airflow/.local/lib/python3.12/site-packages/airflow/sdk/bases/xcom.py, 
line 339 in serialize_value
   File 
/home/airflow/.local/lib/python3.12/site-packages/airflow/serialization/serde.py,
 line 193 in serialize
   ```
   


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-12 Thread via GitHub


Eason09053360 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3890887704

   Tested issue #61673 - ModuleNotFoundError fix works perfectly!


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-12 Thread via GitHub


VladaZakharova commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3890780678

   There are 2 known issues: 1 in the operator of Gemini and serialization, and 
another one for ray job in the system test. I will ping you in those PRs for 
you to include them in RC2


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-12 Thread via GitHub


shahar1 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3890299442

   > -1 For Google provider. Please, move Google provider to RC2
   
   Could please elaborate on the reason(s)? From what you told me in private, 
it seems to do with compatibility of Ray with Airflow 2.11.
   
   1. How and when do you plan to fix it so I could release RC2?
   2. Were there issues with system tests of other Google-related commits 
included in current RC?
   
   
   Thank you!


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-12 Thread via GitHub


VladaZakharova commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3889830615

   -1 For Google provider. Please, move Google provider to RC2


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


amoghrajesh commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3889060211

   My changes:
   
   - Compat change, non functional: https://github.com/apache/airflow/pull/61157
   - Actual change: https://github.com/apache/airflow/pull/61343, tested it and 
works fine
   - Simple sanitisation change: https://github.com/apache/airflow/pull/61624, 
works fine as well


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


nailo2c commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3887587866

   I finished my tests (#61701, #61188); they are all looking good :)


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


anishgirianish commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3887588967

   Tested PR #60805 in `apache-airflow-providers-cncf-kubernetes==10.12.4rc1`.
   
   Verified that the `.get()` fix for optional `reason` and `message` fields in 
`ContainerStateWaiting` is present in the RC package. Simulated the scenario 
where a container status has a `"waiting"` state with no `"reason"` key 
(optional per K8s API spec) — no `KeyError` is raised, and the pod correctly 
stays in pending state.
   
   Fix works as expected.


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


potiuk commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3887270526

   Indeed. Good job. All my changes are in !! 


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


jscheffl commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3887256533

   Thanks Shahr for preparing release!
   
   +1 (binding) - Checked SVN, Check in Docker, Reproducible package build, 
Licenses, Signatures
   
   I did my typical test round with new providers and used Fab and EdgeExecutor 
with the "Integration Test" Dag in Airflow 3.0.6 and 3.1.7 and latest main - no 
errors seen. All good. 


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


henry3260 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3886310713

   All my changes look good!


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


SameerMesiah97 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3886217606

   I can verify that the changes introduced by PRs #61272, #61145, #61051 are 
working as intended in `apache-airflow-providers-amazon==9.22.0rc1`. The 
changes in #61010 could not be fully verified due to personal AWS account 
restrictions but the unit tests indicate that it will work for users. 


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


akshaykumarsalunke commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3886188076

   Tested PR #60440 on AWS EMR, looks good!


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


bugraoz93 commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3885745501

   Hey Shahar, thanks for bringing this together! My changes looks good,


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


andreahlert commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3884404132

   Tested PR #61616 both RCs on Windows/Python 3.12, anyio changes are there. 
Standard provider imports fine. 


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



Re: [I] Status of testing Providers that were prepared on February 10, 2026 [airflow]

2026-02-11 Thread via GitHub


idrisakorede commented on issue #61766:
URL: https://github.com/apache/airflow/issues/61766#issuecomment-3883480409

   I don't currently have access to an EKS environment to test the RC, but
   I've verified the code changes are correct (`. {credentials_file}` and `v1`
   API version). The fix addresses the original issue #60269 as intended.
   
   On Wed, Feb 11, 2026 at 10:40 AM Shahar Epstein ***@***.***>
   wrote:
   
   > *shahar1* left a comment (apache/airflow#61766)
   > 
   >
   > I vouch for most of the changes to the GCP provider, I'll be happy for
   > someone to double-check those that are currently unchecked. Thanks in
   > advance!
   >
   > —
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   > You are receiving this because you were mentioned.Message ID:
   > ***@***.***>
   >
   


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