I like what TP proposed. Even the original pytest style fits my taste better. The unittest style bugs me when I first contributed to Airflow. It’s already way better than it used to be. But, I would love to see it move more towards a pytest style.
Best, Wei > On Jul 10, 2025, at 2:30 PM, Tzu-ping Chung <t...@astronomer.io.INVALID> > wrote: > > Personally I dislike things like assert_called_once_with etc. since they are > easy to miss when you scan a test to see what they are trying to check. An > 'assert' keyword stands out (it’s always the first word in the line), > especially with syntax highlighting. > > I do agree the proposed Pytest style is arguably less readable. I offer > another syntax. > > > from unittest.mock import call > > assert mock_http_run.mock_calls == [ > call( > endpoint=f"api/v2/accounts/{expected_account_id}/", > data=None, > extra_options=None, > ) > ] > assert mock_paginate.mock_calls == [] > > > To me, this is on par with assert_called_once_with et al. in terms of > readability, and arguably better for test authors since you don’t need to > remember the various function names anymore, but only 'mock_calls' and the > 'call' helper class. > > TP > > >> On Jul 9, 2025, at 23:28, Ferruzzi, Dennis <ferru...@amazon.com.INVALID> >> wrote: >> >> I'm a bit late to the party, and really only reiterating what has already >> been said, but of the two examples (original and your rewrite, I prefer the >> original. I think as a general rule, we tend to use the assert_called_once, >> etc with mocks butt he asserts with non-mocked variables. >> >> I am all for more documentation, but I'd have a slight preference towards >> keeping the existing structure. >> >> >> - ferruzzi >> >> >> ________________________________ >> From: Kyungjun Lee <kyungjunlee...@gmail.com> >> Sent: Tuesday, July 8, 2025 2:13 AM >> To: dev@airflow.apache.org >> Subject: RE: [EXT] [DISCUSS] Consistent test assertion style: pytest-native >> vs unittest-style >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you can confirm the sender and know >> the content is safe. >> >> >> >> AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne >> cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas >> confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le >> contenu ne présente aucun risque. >> >> >> >> Thank you Ash and Amogh Desai for your insights and explanations. >> The information you shared has been incredibly helpful and is contributing >> a lot to my growth. >> >> 2025년 7월 8일 (화) 오후 2:54, Amogh Desai <amoghdesai....@gmail.com>님이 작성: >> >>> Agreed, I personally also find the current way to be easier to read and in >>> most >>> cases we want to assert if "something" was called, irrespective of the >>> order it was >>> called in. So the dedicated function based way works well for me. >>> >>> If I want to test a order, I'd rather call parts of code that I want to >>> test explicitly and assert >>> on them. >>> >>>> This happens because the mock object is not properly recognized as a mock >>> instance at type-checking time, which might confuse some contributors, >>> especially new ones relying on type hints or static analysis tools. >>> >>> Regarding this, I'd say you can either cast mocks to their types as one >>> way: >>> `mock_http_run: MagicMock = mock_http_run` -- give or take, or use >>> `autospec` to make the mock reflect the signature of the object? Check out: >>> https://docs.python.org/3/library/unittest.mock.html#autospeccing >>> >>> Thanks & Regards, >>> Amogh Desai >>> >>> >>> On Mon, Jul 7, 2025 at 6:13 PM Ash Berlin-Taylor <a...@apache.org> wrote: >>> >>>> def test_get_account(self, mock_paginate: Mock, mock_http_run: Mocj, >>>> conn_id, account_id): >>>> >>>> >>>> Might fix that? IDEs in general do not cope well with purest tests, and >>>> are missing context on what most of the variables are, be it >>> parameterised >>>> values or fixture values, so this isn’t a problem that is unique to >>> mocks. >>>> >>>>> On 7 Jul 2025, at 12:47, Kyungjun Lee <kyungjunlee...@gmail.com> >>> wrote: >>>>> >>>>> I'd like to follow up on our previous discussion about pytest-native vs >>>>> unittest-style assertions. >>>>> >>>>> While working on the following test case: >>>>> >>>>> ```python >>>>> >>>>> @pytest.mark.parametrize( >>>>> argnames="conn_id, account_id", >>>>> argvalues=[(ACCOUNT_ID_CONN, None), (NO_ACCOUNT_ID_CONN, >>> ACCOUNT_ID)], >>>>> ids=["default_account", "explicit_account"], >>>>> ) >>>>> @patch.object(DbtCloudHook, "run") >>>>> @patch.object(DbtCloudHook, "_paginate") >>>>> def test_get_account(self, mock_paginate, mock_http_run, conn_id, >>>>> account_id): >>>>> hook = DbtCloudHook(conn_id) >>>>> hook.get_account(account_id=account_id) >>>>> >>>>> assert hook.method == "GET" >>>>> >>>>> _account_id = account_id or DEFAULT_ACCOUNT_ID >>>>> hook.run.assert_called_once_with( >>>>> endpoint=f"api/v2/accounts/{_account_id}/", data=None, >>>>> extra_options=None >>>>> ) >>>>> hook._paginate.assert_not_called() >>>>> >>>>> ``` >>>>> >>>>> My IDE shows a warning: >>>>> Cannot find reference 'assert_called_once_with' in 'function'. >>>>> >>>>> This happens because the mock object is not properly recognized as a >>> mock >>>>> instance at type-checking time, which might confuse some contributors, >>>>> especially new ones relying on type hints or static analysis tools. >>>>> >>>>> I realized that this aspect of mock handling might be missing from our >>>>> previous discussions. I wanted to bring it up as part of the broader >>>>> conversation about test styles—particularly how we balance IDE/tooling >>>>> support with readability and style consistency. >>>>> >>>>> Curious to hear your thoughts on this! >>>>> >>>>> @ash @potiuk >>>>> >>>>> 2025년 7월 6일 (일) 오후 8:09, Kyungjun Lee <kyungjunlee...@gmail.com>님이 작성: >>>>> >>>>>> Thank you @Potiuk for pointing out the intent behind the “one assert >>> per >>>>>> test” principle, and @ash for highlighting how using dedicated mock >>>> assert >>>>>> functions can make the code easier to read and understand. These were >>>>>> perspectives I hadn’t fully considered, and I really appreciate you >>>> sharing >>>>>> them. >>>>>> >>>>>> Thanks to your input, I was able to read more materials and broaden my >>>>>> thinking on the topic. That said, my original focus was more on the >>> idea >>>>>> that sticking to plain assert statements lowers the entry barrier for >>>> new >>>>>> contributors—because they don’t have to learn multiple assertion >>> styles. >>>>>> >>>>>> Still, as @Potiuk mentioned, I’ll put more thought into making the >>>> testing >>>>>> guidelines clearer and more concrete—especially since that helps >>>> AI-based >>>>>> tools as well 😄 >>>>>> >>>>>> For reference, here’s one of the articles I read: >>>>>> https://medium.com/@kentbeck_7670/test-desiderata-94150638a4b3 >>>>>> >>>>>> Thank you to everyone who took part in this discussion. >>>>>> >>>>>> 2025년 7월 6일 (일) 오후 3:42, Ash Berlin-Taylor <a...@apache.org>님이 작성: >>>>>> >>>>>>> I personally find the dedicated functions way easier to read the >>> intent >>>>>>> behind, it’s one function/statement vs 3. More so when you don’t care >>>> about >>>>>>> the order of calls, just that something was called (where to do this >>>>>>> manually we’d need to reimplement the helper function) >>>>>>> >>>>>>> Additionally pytest already rewrites those to have nicer error >>>> messages, >>>>>>> but the dedicated mock assert finding are much easier to read the >>> code >>>> and >>>>>>> understand the intent to me, so I’i am for staying with the dedicated >>>>>>> assert functions >>>>>>> >>>>>>> -ash >>>>>>> >>>>>>>> On 5 Jul 2025, at 13:30, Kyungjun Lee <kyungjunlee...@gmail.com> >>>> wrote: >>>>>>>> >>>>>>>> I’ve learned a lot of things I didn’t know before. >>>>>>>> Thank you so much for all your help — I really appreciate it. >>>>>>>> I’ll get started on this right away! >>>>>>>> >>>>>>>> 2025년 7월 5일 (토) 오후 9:18, Jarek Potiuk <ja...@potiuk.com>님이 작성: >>>>>>>> >>>>>>>>>> Haha ... I'm curious — which part sounded like ChatGPT style? >>>>>>>>> English isn't my first language, so I did get a little help from >>> it. >>>>>>>>> >>>>>>>>> That whole paragraph :) . >>>>>>>>> >>>>>>>>>>> Sure! Since you asked for how the test *should* be written, I >>> took >>>>>>> the >>>>>>>>> opportunity to clean it up using a more pytest-native style while >>>> also >>>>>>>>> fixing the mock order issue. >>>>>>>>> >>>>>>>>> "Sure! Since you asked ..." sounds like an AI bot. >>>>>>>>> >>>>>>>>>> That got me thinking — what do you think about adding a guideline >>>>>>>>> document >>>>>>>>> for writing tests, similar to how we have a coding style guide? >>>>>>>>> >>>>>>>>> Absolutely - we already have some "seed' of it "Writing tests" >>>>>>> chapter in >>>>>>>>> contributing guideline, but we could definitely make it more >>>> detailed. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>> https://github.com/apache/airflow/blob/main/contributing-docs/testing/unit_tests.rst#writing-unit-tests >>>>>>>>> >>>>>>>>> And - speaking of AI - this is becoming more and more important to >>>>>>> describe >>>>>>>>> any common rules we have and context - so that using Agentic AI >>>> yields >>>>>>>>> better results. Kaxil already added >>>>>>>>> https://github.com/apache/airflow/blob/main/AGENTS.md which >>>> describes >>>>>>>>> context for coding agents lile Codex - and we could improve it and >>>> link >>>>>>>>> more docs from our repo if they get more of our agreed >>> "conventions" >>>> - >>>>>>> then >>>>>>>>> Agents would get it as context and their generated code would be >>>>>>> consistent >>>>>>>>> with what we describe there. >>>>>>>>> >>>>>>>>> In a way - I think having a good documentation on processes, tools >>>> and >>>>>>>>> conventions was always something I've been after, but with the >>>> Agentic >>>>>>>>> workflows it might significantly boost the quality of generated >>> code >>>>>>> if we >>>>>>>>> have more of those conventions and guidelines described. >>>>>>>>> >>>>>>>>> So .... ABSOLUTELY ... the more we describe in there, the better. >>> And >>>>>>> we >>>>>>>>> have no more excuse that "anyhow no-one reads it" - because the >>>> coding >>>>>>>>> agents WILL be reading it and acting accordingly. So I think this >>> is >>>> a >>>>>>> very >>>>>>>>> good investment to make. >>>>>>>>> >>>>>>>>> J. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sat, Jul 5, 2025 at 2:07 PM Kyungjun Lee < >>>> kyungjunlee...@gmail.com >>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Haha ... I'm curious — which part sounded like ChatGPT style? >>>>>>>>>> English isn't my first language, so I did get a little help from >>> it. >>>>>>>>>> >>>>>>>>>> But thank you — I actually learned something new from your >>> comment! >>>>>>>>>> That got me thinking — what do you think about adding a guideline >>>>>>>>> document >>>>>>>>>> for writing tests, similar to how we have a coding style guide? It >>>>>>> might >>>>>>>>>> help ensure consistency across the Airflow codebase when it comes >>> to >>>>>>>>>> testing styles as well. >>>>>>>>>> >>>>>>>>>> 2025년 7월 5일 (토) 오후 8:52, Jarek Potiuk <ja...@potiuk.com>님이 작성: >>>>>>>>>> >>>>>>>>>>> But of course - i'd love to hear what others think - it's not a >>>> "very >>>>>>>>>>> strong" opinion. >>>>>>>>>>> >>>>>>>>>>> On Sat, Jul 5, 2025 at 1:48 PM Jarek Potiuk <ja...@potiuk.com> >>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Cool. That's what I wanted to see. >>>>>>>>>>>> >>>>>>>>>>>> By the way - not that there's anything wrong - but was the >>> answer >>>>>>>>>> written >>>>>>>>>>>> by AI initially ? The first paragraph looks suspiciously like >>> Chat >>>>>>>>> GPT >>>>>>>>>>>> answer :D ? >>>>>>>>>>>> >>>>>>>>>>>> Comment from my side: I personally prefer the original style. >>> It's >>>>>>>>> more >>>>>>>>>>>> concise and it is easier to read - you see as if the call was >>>>>>>>> actually >>>>>>>>>>>> written down. Also this is quite a bit too many assertions in >>> the >>>>>>>>>> second >>>>>>>>>>>> case and it takes a lot of mental effort to understand what >>>> actually >>>>>>>>> is >>>>>>>>>>>> being asserted. >>>>>>>>>>>> >>>>>>>>>>>> There is a "school" of writing unit tests that every test should >>>>>>> have >>>>>>>>>> ONE >>>>>>>>>>>> assertion only. Always. I think it is a bit extreme, and I do >>> not >>>>>>>>>> follow >>>>>>>>>>> it >>>>>>>>>>>> myself but I think it is also a kind of good direction to have >>> -> >>>>>>> the >>>>>>>>>>> fewer >>>>>>>>>>>> assertions you have in your test, the better (I think). >>>>>>>>>>>> >>>>>>>>>>>> I think tests should be mostly optimized for easiness of reading >>>> and >>>>>>>>>>>> understanding what is being tested - and it's just not that easy >>>> in >>>>>>>>> the >>>>>>>>>>>> second case. >>>>>>>>>>>> >>>>>>>>>>>> J. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Jul 5, 2025 at 1:39 PM Kyungjun Lee < >>>>>>>>> kyungjunlee...@gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Sure! Since you asked for how the test *should* be written, I >>>> took >>>>>>>>> the >>>>>>>>>>>>> opportunity to clean it up using a more pytest-native style >>> while >>>>>>>>> also >>>>>>>>>>>>> fixing the mock order issue. >>>>>>>>>>>>> >>>>>>>>>>>>> Here’s the updated test: >>>>>>>>>>>>> >>>>>>>>>>>>> ```python >>>>>>>>>>>>> >>>>>>>>>>>>> @pytest.mark.parametrize( >>>>>>>>>>>>> argnames="conn_id, account_id", >>>>>>>>>>>>> argvalues=[(ACCOUNT_ID_CONN, None), (NO_ACCOUNT_ID_CONN, >>>>>>>>>>> ACCOUNT_ID)], >>>>>>>>>>>>> ids=["default_account", "explicit_account"], >>>>>>>>>>>>> ) >>>>>>>>>>>>> @patch.object(DbtCloudHook, "run") >>>>>>>>>>>>> @patch.object(DbtCloudHook, "_paginate") >>>>>>>>>>>>> def test_get_account(self, mock_paginate, mock_http_run, >>> conn_id, >>>>>>>>>>>>> account_id): >>>>>>>>>>>>> hook = DbtCloudHook(conn_id) >>>>>>>>>>>>> hook.get_account(account_id=account_id) >>>>>>>>>>>>> >>>>>>>>>>>>> assert hook.method == "GET" >>>>>>>>>>>>> >>>>>>>>>>>>> expected_account_id = account_id or DEFAULT_ACCOUNT_ID >>>>>>>>>>>>> >>>>>>>>>>>>> assert mock_http_run.call_count == 1 >>>>>>>>>>>>> assert mock_http_run.call_args.args == () >>>>>>>>>>>>> assert mock_http_run.call_args.kwargs == { >>>>>>>>>>>>> "endpoint": f"api/v2/accounts/{expected_account_id}/", >>>>>>>>>>>>> "data": None, >>>>>>>>>>>>> "extra_options": None, >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> assert mock_paginate.call_count == 0 >>>>>>>>>>>>> >>>>>>>>>>>>> ``` >>>>>>>>>>>>> Why I chose this style: >>>>>>>>>>>>> >>>>>>>>>>>>> - >>>>>>>>>>>>> >>>>>>>>>>>>> *Mock verification using assert*: Instead of >>>>>>>>>>>>> mock.assert_called_once_with(...), I used call_count and >>>>>>>>> call_args. >>>>>>>>>>>>> This >>>>>>>>>>>>> approach aligns better with pytest’s idioms and produces >>>> cleaner, >>>>>>>>>>> more >>>>>>>>>>>>> readable error messages when assertions fail. >>>>>>>>>>>>> - >>>>>>>>>>>>> >>>>>>>>>>>>> *Explicit verification*: Using call_args.args and >>>>>>>>> call_args.kwargs >>>>>>>>>>>>> makes >>>>>>>>>>>>> the test behavior very explicit, which helps with debugging >>> and >>>>>>>>>>>>> understanding the exact calls made. >>>>>>>>>>>>> - >>>>>>>>>>>>> >>>>>>>>>>>>> *Decorator order matching argument order*: As @patch >>> decorators >>>>>>>>>> apply >>>>>>>>>>>>> from the bottom up, the argument order has been corrected to >>>>>>>>> match >>>>>>>>>> ( >>>>>>>>>>>>> mock_paginate first, then mock_http_run). >>>>>>>>>>>>> >>>>>>>>>>>>> Let me know if you'd like to follow a slightly different >>>> convention >>>>>>>>> — >>>>>>>>>>>>> happy >>>>>>>>>>>>> to adjust! >>>>>>>>>>>>> >>>>>>>>>>>>> I was lucky to have the chance to explain this while fixing a >>>>>>>>> related >>>>>>>>>>> bug. >>>>>>>>>>>>> You can refer to the changes in this PR: >>>>>>>>>>>>> https://github.com/apache/airflow/pull/52905 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2025년 7월 5일 (토) 오후 8:09, Jarek Potiuk <ja...@potiuk.com>님이 작성: >>>>>>>>>>>>> >>>>>>>>>>>>>> Just post how you think the test should be written :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Jul 5, 2025 at 1:08 PM Jarek Potiuk <ja...@potiuk.com >>>> >>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I already mentioned it in slack - but how would you propose >>> to >>>>>>>>>>> rewrite >>>>>>>>>>>>>> the >>>>>>>>>>>>>>> "mixed" case to be more consistent ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Jul 5, 2025 at 12:47 PM Kyungjun Lee < >>>>>>>>>>>>> kyungjunlee...@gmail.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> While reviewing and contributing to Airflow tests, I’ve >>>> noticed >>>>>>>>>> an >>>>>>>>>>>>>>>> inconsistency in how assertions are written. Some tests use >>>>>>>>>>>>>>>> `unittest`-style assertions like >>>>>>>>> `mock.assert_called_once_with`, >>>>>>>>>>>>> while >>>>>>>>>>>>>>>> others use plain `assert` statements in the `pytest` style. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Here's an example of a test using the mixed style: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ```python >>>>>>>>>>>>>>>> @pytest.mark.parametrize( >>>>>>>>>>>>>>>> argnames="conn_id, account_id", >>>>>>>>>>>>>>>> argvalues=[(ACCOUNT_ID_CONN, None), (NO_ACCOUNT_ID_CONN, >>>>>>>>>>>>>> ACCOUNT_ID)], >>>>>>>>>>>>>>>> ids=["default_account", "explicit_account"], >>>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>>> @patch.object(DbtCloudHook, "run") >>>>>>>>>>>>>>>> @patch.object(DbtCloudHook, "_paginate") >>>>>>>>>>>>>>>> def test_get_account(self, mock_http_run, mock_paginate, >>>>>>>>> conn_id, >>>>>>>>>>>>>>>> account_id): >>>>>>>>>>>>>>>> hook = DbtCloudHook(conn_id) >>>>>>>>>>>>>>>> hook.get_account(account_id=account_id) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> assert hook.method == "GET" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _account_id = account_id or DEFAULT_ACCOUNT_ID >>>>>>>>>>>>>>>> hook.run.assert_called_once_with( >>>>>>>>>>>>>>>> endpoint=f"api/v2/accounts/{_account_id}/", data=None, >>>>>>>>>>>>>>>> extra_options=None >>>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>>> hook._paginate.assert_not_called() >>>>>>>>>>>>>>>> ``` >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In IDEs and type-checkers (like PyCharm or MyPy), this >>>>>>>>> sometimes >>>>>>>>>>>>> causes >>>>>>>>>>>>>>>> weak warnings >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ``` >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cannot find reference 'assert_called_once_with' in >>> 'function' >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ``` >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This could confuse newcomers or contributors unfamiliar with >>>>>>>>>>> mocking >>>>>>>>>>>>>>>> behavior or type limitations in dynamic typing. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To improve clarity and accessibility for >>>>>>>>> contributors—especially >>>>>>>>>>>>> those >>>>>>>>>>>>>> new >>>>>>>>>>>>>>>> to the project—I’d like to propose *moving toward consistent >>>>>>>>> use >>>>>>>>>> of >>>>>>>>>>>>>> plain >>>>>>>>>>>>>>>> assert statements* for test validations wherever possible. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Proposed Benefits*: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Easier onboarding for first-time contributors >>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Better IDE support and fewer confusing warnings >>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> More consistent and readable test style across the project >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'd love to hear your thoughts on whether this direction >>> makes >>>>>>>>>>> sense >>>>>>>>>>>>> for >>>>>>>>>>>>>>>> the project. If agreed, I’d also be happy to help align >>>>>>>>> existing >>>>>>>>>>>>> tests >>>>>>>>>>>>>>>> gradually. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>> Kyungjun Lee >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org >>>>>>> For additional commands, e-mail: dev-h...@airflow.apache.org >>>>>>> >>>>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org >>>> For additional commands, e-mail: dev-h...@airflow.apache.org >>>> >>>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > For additional commands, e-mail: dev-h...@airflow.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org