Just to give a warning on that one (as explained in https://github.com/apache/airflow/issues/53395#issuecomment-3081366009)
I personally have a strange love-hate relationship with MyPy. On one hand it is really helpful to detect some issues (often directly in the IDE), on the other hand its results can vary depending on the "state" (namely cache) and the files it gets as input. MyPy - as I understand it - guesses what some of the types are based on complex heuristics, and sometimes it will not guess it or guess it wrongly if it does not have all the information. So those warnings might be different depending on your cache state and whether you run it on "all files" or. a subset of those. And it's not really 100% deterministic. Also that's why some of the warnings might be confusing and wrong. Because of that I am not sure if we can "heavily" and "sustainably" depend on that warning and even reproducibility of them might be a challenge (as exhibited in https://github.com/apache/airflow/issues/53395). I have no "easy solution" to the issue, other than "only fix things that are reported on clean cache and running mypy with all provider files" (which Airflow CI does as "golden standard") . Maybe our goal should be to fix all the warnings in this "single' setup and turn it into an error in CI when all of those are fixed and mark all the "false positives" as # type: ignore[...]. And then (because of the non-deterministic behaviour) we should not clean that # type ignore if it appears to be unused (which I guess will start happening if we run mypy incrementally). Or am I talking nonsense - and I misunderstood the problems described in https://github.com/apache/airflow/issues/53395 :) ? J. On Wed, Jul 16, 2025 at 8:29 PM Ankit Chaurasia <sunank...@gmail.com> wrote: > Thank you for the detailed description on the issue. I have picked up a few > providers. > > *Ankit Chaurasia* > > > > > > > On Wed, Jul 16, 2025 at 11:12 PM Pavankumar Gopidesu < > gopidesupa...@gmail.com> wrote: > > > Hello All, > > > > I am back with one more kind request, This time fixing/cleaning up > > unreachable code. > > > > Jens and I were discussing this, we scanned the providers in our codebase > > by enabling the --warn-unreachable flag in mypy. It turns out we > > encountered around 120 warnings. > > > > Some of these warnings might be false positives, as the code appears to > > have valid logic in certain cases. However, mypy flags them as > unreachable. > > That said, some of the warnings do highlight actual issues worth > > investigating and fix where possible. > > > > When we did mypy ignore cleanup we found some are actual issues and fixed > > them as part of the cleanup process. > > > > I have a kind request to maintainers who are expert in their areas if any > > PR appears on the board, could you please help in review and help any > > potential side effects with the changes. > > > > To all contributors: If you're picking up any of these tasks, please > ensure > > you're comfortable with the codebase you're modifying and aware of any > > potential side effects your changes may introduce. Also these are good > > tasks to get familiar with code for the related issues :) Please feel > free > > to call out where you need any help. > > > > Hope doing this activity is worth fixing if any bugs are found. > > > > Details are here: https://github.com/apache/airflow/issues/53395 > > > > Reference PR: https://github.com/apache/airflow/pull/53414 > > > > Thanks , looking forward to your contributions. > > > > Pavan > > >
