-
Notifications
You must be signed in to change notification settings - Fork 14.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
Refactored waiting function for Tableau Jobs #17034
Refactored waiting function for Tableau Jobs #17034
Conversation
while finish_code == TableauJobFinishCode.PENDING: | ||
finish_code = self.get_job_status(job_id=job_id) |
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.
Do we risk here to overwhelm the Tableau API?
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.
Yeah you're right especially for a long refresh. But now I am a little bit confused, the original request was to remove the sensor from the operator and to implement the waiting code in the hook. But why just not use the sensor and the already implemented poke function instead to create a new one?
What do you think?
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 have the issue of waiting for a specific status in other operators.
For example:
EC2StartInstanceOperator
allows to pass check_interval
to the wait_for_state
function in the hook:
airflow/airflow/providers/amazon/aws/operators/ec2_start_instance.py
Lines 65 to 69 in 1960e37
ec2_hook.wait_for_state( | |
instance_id=self.instance_id, | |
target_state="running", | |
check_interval=self.check_interval, | |
) |
That way we provide the user the power to decide how much time to wait.
BTW I think it would be nice to change the waiting_until_succeeded
to a genericwait_for_state
like it's implemented in the EC2Hook
that way it will allow more flexibility and users may use it for further custom operators if they need to. For our use case we can wait tillTableauJobFinishCode.SUCCESS
.
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.
Ok. Now it's more clear. I will implement the changes.
Thank you.
Many whitespace changes besides |
36ee4e6
to
8c0c9ac
Compare
I pushed the requested changes. Just a comment, the function |
# Test SUCCESS | ||
mock_tableau_server.jobs.get_by_id.return_value.finish_code = 0 | ||
with TableauHook(tableau_conn_id='tableau_test_password') as tableau_hook: | ||
tableau_hook.server = mock_tableau_server | ||
jobs_status = tableau_hook.get_job_status(job_id='j1') | ||
assert jobs_status == TableauJobFinishCode.SUCCESS | ||
|
||
# Test ERROR | ||
mock_tableau_server.jobs.get_by_id.return_value.finish_code = 1 | ||
with TableauHook(tableau_conn_id='tableau_test_password') as tableau_hook: | ||
tableau_hook.server = mock_tableau_server | ||
jobs_status = tableau_hook.get_job_status(job_id='j1') | ||
assert jobs_status == TableauJobFinishCode.ERROR |
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.
Lets also add test case for CANCELED
Also we have a repeated pattern here probably better to use parameterized test
side_effect=[ | ||
TableauJobFinishCode.PENDING, | ||
TableauJobFinishCode.PENDING, | ||
TableauJobFinishCode.ERROR, | ||
], |
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.
Why PENDING twice?
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 wanted to simulate a more realistic case, just to be more secure that everything was ok.
I read wrong before. You're right, in this case, it is not necessary.
…ok and updated Sensor and Operator.
8c0c9ac
to
e79c63f
Compare
Pushed requested changes. Just a comment, I didn't parametrize the |
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 this is good in the sense that it should do what you want it to do, but I’m not really familiar with Tebleau to comment further.
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.
LTGM
please fix/explain the duplication (there were 4 tests with the duplicated values you addressed only 1 of them)
Other than that looks OK
@potiuk since you approved the PR that we splitted out from. Do you have any further comments? |
The PR is likely OK to be merged with just subset of tests for default Python and Database versions without running the full matrix of tests, because it does not modify the core of Airflow. If the committers decide that the full tests matrix is needed, they will add the label 'full tests needed'. Then you should rebase to the latest main or amend the last commit of the PR, and push it with --force-with-lease. |
Hello all,
as suggested in PR #16937 I created a new PR with the following changes:
TableauHook
TableauJobStatusSensor
, inTableauRefreshWorkbookOperator
TableauJobStatusSensor
Thank you