Repository navigation
Fix plugin registration returning early on duplicate names - #60498
Conversation
|
Can you add unit tests please - that would avoid future similar regressions |
|
:D ? Would be great to have a unit test so that we can back-port it to 3.1.7 |
I'm a bit behind because I'm traveling. Will add asap. :-) |
He He... tell me more about travelling and beig behind :) |
0d1f7cb to
9ba03dd
Compare
|
@potiuk I counterchecked against other current PRs and the doc test failures are unrelated to this commit. |
|
Yep. We had an issue yesterday that setuptools new release broke sphinx extension. Rebasing should help, it's already addressed in main. |
The __register_plugins function was using 'return' instead of 'continue' when encountering a duplicate plugin name. This caused the entire loop to exit early, preventing subsequent plugins from being loaded. Fixes a bug in apache#32692.
9ba03dd to
cb3ccef
Compare
Backport failed to create: v3-1-test. View the failure log Run details
You can attempt to backport this manually by running: cherry_picker cf47121 v3-1-testThis should apply the commit to the v3-1-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continueIf you don't have cherry-picker installed, see the installation guide. |
) The __register_plugins function was using 'return' instead of 'continue' when encountering a duplicate plugin name. This caused the entire loop to exit early, preventing subsequent plugins from being loaded. Fixes a bug in apache#32692.
) The __register_plugins function was using 'return' instead of 'continue' when encountering a duplicate plugin name. This caused the entire loop to exit early, preventing subsequent plugins from being loaded. Fixes a bug in apache#32692.
) The __register_plugins function was using 'return' instead of 'continue' when encountering a duplicate plugin name. This caused the entire loop to exit early, preventing subsequent plugins from being loaded. Fixes a bug in apache#32692.
|
__register_plugins is not in v3-1-test |
) The __register_plugins function was using 'return' instead of 'continue' when encountering a duplicate plugin name. This caused the entire loop to exit early, preventing subsequent plugins from being loaded. Fixes a bug in apache#32692.
) The __register_plugins function was using 'return' instead of 'continue' when encountering a duplicate plugin name. This caused the entire loop to exit early, preventing subsequent plugins from being loaded. Fixes a bug in apache#32692.
) The __register_plugins function was using 'return' instead of 'continue' when encountering a duplicate plugin name. This caused the entire loop to exit early, preventing subsequent plugins from being loaded. Fixes a bug in apache#32692.
) The __register_plugins function was using 'return' instead of 'continue' when encountering a duplicate plugin name. This caused the entire loop to exit early, preventing subsequent plugins from being loaded. Fixes a bug in apache#32692.
#72253) __register_plugins used `return` instead of `continue` when encountering a duplicate plugin name, so the first duplicate abandoned the rest of the batch and every plugin after it was silently dropped. airflow-core carries a duplicate of this function and was fixed twice: in #60498 (`return` became a warning plus `continue`) and in #66649 (also record the duplicate in import_errors). Neither fix reached the Task SDK copy. Because that copy is the one used by the task-running process, plugins would load for the scheduler and API server but silently go missing inside tasks - most visibly, task instance listeners registered by a plugin would never fire. The __register_plugins body is now byte-identical to the airflow-core one.
apache#72253) __register_plugins used `return` instead of `continue` when encountering a duplicate plugin name, so the first duplicate abandoned the rest of the batch and every plugin after it was silently dropped. airflow-core carries a duplicate of this function and was fixed twice: in apache#60498 (`return` became a warning plus `continue`) and in apache#66649 (also record the duplicate in import_errors). Neither fix reached the Task SDK copy. Because that copy is the one used by the task-running process, plugins would load for the scheduler and API server but silently go missing inside tasks - most visibly, task instance listeners registered by a plugin would never fire. The __register_plugins body is now byte-identical to the airflow-core one.
The __register_plugins function was using 'return' instead of 'continue' when encountering a duplicate plugin name. This caused the entire loop to exit early, preventing subsequent plugins from being loaded.