-
Notifications
You must be signed in to change notification settings - Fork 16.4k
Improve subclassing of TaskSDK's WatchedSubprocess #45570
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| self.parsing_result = msg | ||
| return | ||
| # GetVariable etc -- parsing a dag can run top level code that asks for an Airflow Variable | ||
| super()._handle_request(msg, log) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would have never worked, it would have tried to use self.client which is None and would have thrown an exception
| ) | ||
|
|
||
| # Tell the task process what it needs to do! | ||
| proc._on_child_started(what, path, requests_fd) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calling this is now the responsibility of the subclasses overridden start methods
|
|
||
| self._handle_request(msg, log) | ||
|
|
||
| def _handle_request(self, msg, log: FilteringBoundLogger) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
msg here is not typed in the base class on purpose.
When I added the DagFileProcessorProcess I did some naughty things with subclassing and lying to the type checker, and this is now stopping us easily adding DAG bundles (because as it is structured right now we would have to change both parsing and execution at the same time, or make the type checker _even more unhappy_.) This more correctly separates the two classes -- essentially anything that used `self.client` couldn't have been called from a DagFileProcessorProcess (as client was always None for those instances). This PR fixes it by adding a new `ActivitySubprocess` which is the type used at Execution time (the one that always has the client) and the base behaviour kept in WatchedSubprocess.
83c099e to
bfd88fb
Compare
|
Tests are failing with this: which I think main is suffering from too. |
|
Yup, issue is unrelated, fix is #45572. Merging this |
Follow-up of apache#45570 to add some Typehints so my editor (PyCharm) can find `_on_child_started`. Added/Updated docstrings since `WatchedSubprocess` is now a Base class. and removed redundant exception handling for `init_log_file`
Follow-up of #45570 to add some Typehints so my editor (PyCharm) can find `_on_child_started`. Added/Updated docstrings since `WatchedSubprocess` is now a Base class. and removed redundant exception handling for `init_log_file`
When I added the DagFileProcessorProcess I did some naughty things with subclassing and lying to the type checker, and this is now stopping us easily adding DAG bundles (because as it is structured right now we would have to change both parsing and execution at the same time, or make the type checker _even more unhappy_.) This more correctly separates the two classes -- essentially anything that used `self.client` couldn't have been called from a DagFileProcessorProcess (as client was always None for those instances). This PR fixes it by adding a new `ActivitySubprocess` which is the type used at Execution time (the one that always has the client) and the base behaviour kept in WatchedSubprocess.
Follow-up of apache#45570 to add some Typehints so my editor (PyCharm) can find `_on_child_started`. Added/Updated docstrings since `WatchedSubprocess` is now a Base class. and removed redundant exception handling for `init_log_file`
When I added the DagFileProcessorProcess I did some naughty things with subclassing and lying to the type checker, and this is now stopping us easily adding DAG bundles (because as it is structured right now we would have to change both parsing and execution at the same time, or make the type checker _even more unhappy_.) This more correctly separates the two classes -- essentially anything that used `self.client` couldn't have been called from a DagFileProcessorProcess (as client was always None for those instances). This PR fixes it by adding a new `ActivitySubprocess` which is the type used at Execution time (the one that always has the client) and the base behaviour kept in WatchedSubprocess.
Follow-up of apache#45570 to add some Typehints so my editor (PyCharm) can find `_on_child_started`. Added/Updated docstrings since `WatchedSubprocess` is now a Base class. and removed redundant exception handling for `init_log_file`
When I added the DagFileProcessorProcess I did some naughty things with subclassing and lying to the type checker, and this is now stopping us easily adding DAG bundles (because as it is structured right now we would have to change both parsing and execution at the same time, or make the type checker _even more unhappy_.) This more correctly separates the two classes -- essentially anything that used `self.client` couldn't have been called from a DagFileProcessorProcess (as client was always None for those instances). This PR fixes it by adding a new `ActivitySubprocess` which is the type used at Execution time (the one that always has the client) and the base behaviour kept in WatchedSubprocess.
Follow-up of apache#45570 to add some Typehints so my editor (PyCharm) can find `_on_child_started`. Added/Updated docstrings since `WatchedSubprocess` is now a Base class. and removed redundant exception handling for `init_log_file`
When I added the DagFileProcessorProcess I did some naughty things with subclassing and lying to the type checker, and this is now stopping us easily adding DAG bundles (because as it is structured right now we would have to change both parsing and execution at the same time, or make the type checker _even more unhappy_.) This more correctly separates the two classes -- essentially anything that used `self.client` couldn't have been called from a DagFileProcessorProcess (as client was always None for those instances). This PR fixes it by adding a new `ActivitySubprocess` which is the type used at Execution time (the one that always has the client) and the base behaviour kept in WatchedSubprocess.
Follow-up of apache#45570 to add some Typehints so my editor (PyCharm) can find `_on_child_started`. Added/Updated docstrings since `WatchedSubprocess` is now a Base class. and removed redundant exception handling for `init_log_file`
Follow-up of apache/airflow#45570 to add some Typehints so my editor (PyCharm) can find `_on_child_started`. Added/Updated docstrings since `WatchedSubprocess` is now a Base class. and removed redundant exception handling for `init_log_file` GitOrigin-RevId: 168f76562e617cd8e8a41ec684bfda09db6b5705
Follow-up of apache/airflow#45570 to add some Typehints so my editor (PyCharm) can find `_on_child_started`. Added/Updated docstrings since `WatchedSubprocess` is now a Base class. and removed redundant exception handling for `init_log_file` GitOrigin-RevId: 168f76562e617cd8e8a41ec684bfda09db6b5705
Follow-up of apache/airflow#45570 to add some Typehints so my editor (PyCharm) can find `_on_child_started`. Added/Updated docstrings since `WatchedSubprocess` is now a Base class. and removed redundant exception handling for `init_log_file` GitOrigin-RevId: 168f76562e617cd8e8a41ec684bfda09db6b5705
When I added the DagFileProcessorProcess I did some naughty things with
subclassing and lying to the type checker, and this is now stopping us easily
adding DAG bundles (because as it is structured right now we would have to
change both parsing and execution at the same time, or make the type checker
even more unhappy.)
This more correctly separates the two classes -- essentially anything that
used
self.clientcouldn't have been called from a DagFileProcessorProcess(as client was always None for those instances).
This PR fixes it by adding a new
ActivitySubprocesswhich is the type usedat Execution time (the one that always has the client) and the base behaviour
kept in WatchedSubprocess.
Closes #45537 as it is an alternative implementation of addressing the same problem
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in newsfragments.