-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Fix double logging with some task logging handler #27591
Fix double logging with some task logging handler #27591
Conversation
|
||
|
||
def __getattr__(name): | ||
if name in ("DISABLE_PROPOGATE", "DISABLE_PROPAGATE"): |
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.
:D
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.
We all knew I couldn't spell right?
(The switch to an Enum was for typing reasons, no easy way of saying "returns none or this specific object type")
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.
Looking forward to the depreciation warning hahahaha :D
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.
Luckily in this case I don't think we need one: it was only for a single point release, and it didn't really work in practice
😅
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.
But I want to see you suffer 😆 You need to learn from those mistakes 😆
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.
NEVER!
Nice |
It appears my PR skills have attrophied to the point where I'm just making silly mistakes :D |
A previous change to fix disappearing log messages turned on propagation for the `airflow.task` logger, and disabled it again after `set_context()` was called, but only if that function returned a special sentinel value. For the "core" task log handlers we returned them, but some providers weren't "correctly" subclassing and weren't returning this sentinel value. The fix here is to change the logic from disable only on speical value to disable by default and maintain propagation on special value; this means that if a handler doesn't return the value from `super()` (or if they don't even subclass the default handler) propagation will still be disabled by default.
…ore Secrets Backend (apache#27134)
4820ec6
to
d7f50d8
Compare
A previous change to fix disappearing log messages turned on propagation for the `airflow.task` logger, and disabled it again after `set_context()` was called, but only if that function returned a special sentinel value. For the "core" task log handlers we returned them, but some providers weren't "correctly" subclassing and weren't returning this sentinel value. The fix here is to change the logic from disable only on special value to disable by default and maintain propagation on special value; this means that if a handler doesn't return the value from `super()` (or if they don't even subclass the default handler) propagation will still be disabled by default. (cherry picked from commit 933fefc)
A previous change to fix disappearing log messages turned on propagation for the `airflow.task` logger, and disabled it again after `set_context()` was called, but only if that function returned a special sentinel value. For the "core" task log handlers we returned them, but some providers weren't "correctly" subclassing and weren't returning this sentinel value. The fix here is to change the logic from disable only on special value to disable by default and maintain propagation on special value; this means that if a handler doesn't return the value from `super()` (or if they don't even subclass the default handler) propagation will still be disabled by default. (cherry picked from commit 933fefc)
A previous change to fix disappearing log messages turned on propagation for the `airflow.task` logger, and disabled it again after `set_context()` was called, but only if that function returned a special sentinel value. For the "core" task log handlers we returned them, but some providers weren't "correctly" subclassing and weren't returning this sentinel value. The fix here is to change the logic from disable only on special value to disable by default and maintain propagation on special value; this means that if a handler doesn't return the value from `super()` (or if they don't even subclass the default handler) propagation will still be disabled by default.
A previous change to fix disappearing log messages turned on propagation for the
airflow.task
logger, and disabled it again afterset_context()
was called, but only if that function returned a special sentinel value.For the "core" task log handlers we returned them, but some providers weren't "correctly" subclassing and weren't returning this sentinel value.
The fix here is to change the logic from disable only on special value to disable by default and maintain propagation on special value; this means that if a handler doesn't return the value from
super()
(or if they don't even subclass the default handler) propagation will still be disabled by default.Fixes #27345