-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[airflow] Add lint rule to show error for removed context variables in airflow #15144
base: main
Are you sure you want to change the base?
[airflow] Add lint rule to show error for removed context variables in airflow #15144
Conversation
|
89ed2ce
to
c3fb996
Compare
from airflow.decorators import task | ||
|
||
@task | ||
def print_config(**context): |
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.
There are some more things we should check
- Named keyword arguments (e.g.
def print_config(execution_date)
) - Getting the context with
get_current_context
instead of function arguments. context
in an operator’sexecute
.
These can be added in separate PRs instead after this is merged.
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.
I have added logic for other ways to access context value as well. It is part of tests.
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.
For Named keyword arguments (e.g. def print_config(execution_date))
I can create a separate PR
if id.as_str() == "context" { | ||
if let Some(key) = extract_name_from_slice(slice) { | ||
const REMOVED_CONTEXT_KEYS: [&str; 11] = [ | ||
"execution_date", |
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.
"conf" had also been removed
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.
It's tracked in apache/airflow#45212, but yep, we could do it here as well
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.
If we want to add conf
here, it would be awesome if we could include triggering_dataset_events
→ triggering_asset_events
. If not, I can make a separate PR
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.
I have added conf
removal check. include triggering_dataset_events
→ triggering_asset_events
can be part of another PR
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.
If conf
has been added, could you please update the description as well? Thanks!
...rc/rules/airflow/snapshots/ruff_linter__rules__airflow__tests__AIR302_AIR302_context.py.snap
Outdated
Show resolved
Hide resolved
@task | ||
def print_config(**context): | ||
# This should not throw an error as logical_date is part of airflow context. | ||
logical_date = context["logical_date"] |
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.
@sunank200 and I discussed this earlier. What we're trying to check is whether there's a variable named as context
in a function (most commonly seen in taskflow and python operator) and whether it's can be accessed like a dict with the keys we want to check. I think it's unlikely users are using something like this out of the airflow context. But would like to know whether there's any concern
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.
I have added logic for other ways to access context value as well. It is part of tests.
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.
It’s probably better to detect
- Arguments of a function decorated with
@task
(either**
or simple named arguments). (As a follow-up, any functions called by such a function) - The
execute
function of a BaseOperator subclass (As a follow-up, any functions called byexecute
) - The dict returned by
get_current_context
.
This should be better than detecting with variable name.
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.
What about python_callable
?
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.
I don’t think python_callable
takes the context though? It only accepts things you provide in self.op_args
and self.op_kwargs
.
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.
I agree that it'll be useful to guard this check by first verifying that the parameter is coming from a function which is decorated with a @task
.
I think this can be done as a pre-check for context variables by using the checker.semantic().current_statements()
method to traverse up the AST to find the function definition node and checking whether the function has a @task
decorator that originates from the airflow
module.
ruff/crates/ruff_python_semantic/src/model.rs
Lines 1232 to 1239 in 9fd4eb8
/// Returns an [`Iterator`] over the current statement hierarchy, from the current [`Stmt`] | |
/// through to any parents. | |
pub fn current_statements(&self) -> impl Iterator<Item = &'a Stmt> + '_ { | |
let id = self.node_id.expect("No current node"); | |
self.nodes | |
.ancestor_ids(id) | |
.filter_map(move |id| self.nodes[id].as_statement()) | |
} |
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.
I don’t think
python_callable
takes the context though? It only accepts things you provide inself.op_args
andself.op_kwargs
.
I though we can still get it in the python_callable? https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html#pythonoperator
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.
Hmm OK I didn’t even realise you can do that… yeah in that case it’s probably a good idea to also detect python_callable
arguments.
5c96f89
to
5103ef7
Compare
@task | ||
def print_config(**context): | ||
# This should not throw an error as logical_date is part of airflow context. | ||
logical_date = context["logical_date"] |
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.
What about python_callable
?
crates/ruff_linter/resources/test/fixtures/airflow/AIR302_context.py
Outdated
Show resolved
Hide resolved
|
||
if let Expr::Subscript(ExprSubscript { value, slice, .. }) = expr { | ||
if let Expr::Name(ExprName { id, .. }) = &**value { | ||
if id.as_str() == "context" { |
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.
I think we'd also need to check where the context
variable is originating from otherwise, I think, this will raise a violation on all variables that's named "context" and is using a similar access pattern.
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.
i.e., we need to make sure that the definition of context
variable is the function parameter that's decorated with @task
.
6da5dd9
to
d580a4b
Compare
add lint rule to show error for removed context variables in airflow
d580a4b
to
c0a34d3
Compare
pub(crate) fn removed_context_variable(checker: &mut Checker, expr: &Expr) { | ||
const REMOVED_CONTEXT_KEYS: [&str; 12] = [ | ||
"conf", | ||
"execution_date", |
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.
For execution_date
there is actually a replacement - in the docs: https://airflow.apache.org/docs/apache-airflow/stable/templates-ref.html#deprecated-variables - can you add this?
(Same for next_execution_date, prev_execution_date)
Summary
Airflow 3.0 removes following deprecated Airflow context variables:
They have been deprecated in 2.x, but the removal causes incompatibilities that we want to detect.
related: #44409, #41641
Test Plan
A test fixture is included in the PR.