-
Notifications
You must be signed in to change notification settings - Fork 14.3k
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-3632] Allow replace_microseconds in trigger_dag REST request #6380
Conversation
666ab50
to
48e1602
Compare
Codecov Report
@@ Coverage Diff @@
## master #6380 +/- ##
==========================================
- Coverage 83.83% 83.82% -0.01%
==========================================
Files 651 651
Lines 37431 37437 +6
==========================================
+ Hits 31379 31383 +4
- Misses 6052 6054 +2
Continue to review full report at Codecov.
|
33354af
to
608c57a
Compare
@ashb is it possible to re-run a step in Travis? the test that's failing on only one of the environments now doesn't seem to have anything to do with these changes |
@acroos Re-run that stage. (It needs someone with write access to the repo to hit the button) |
@@ -107,7 +107,7 @@ def trigger_dag( | |||
:param run_id: ID of the dag_run | |||
:param conf: configuration | |||
:param execution_date: date of execution | |||
:param replace_microseconds: whether microseconds should be zeroed | |||
:param replace_microseconds: whether microseconds should be zeroed (ignored if execution_date is given) |
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'm not sure if it matters, but the view in airflow/www/api/experimental/endpoints.py
doesn't pass through a replace_microseconds parameter, so there's no way of setting this to anything that the default True from the REST 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.
that's true, maybe would be nice to add that as well.
@ashb any further changes I should make? or anything else I need to make this merge-able? |
@ashb sorry to bother you, just wanted to check if there's anything else I should do so this can be merged? |
Ack sorry, no this is just waiting on me (or another commiter!) to find time to review it again. |
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.
Code I think looks good, but we need a note in UPDATING.md about this change.
Is it possible to get the old behaviour back by explicitly passing replace_microsecond=True in the API call? If not could you please add a way to get the old behaviour back just in case someone is depending upon it.
@ashb can I clarify the exact behavior that you're expecting? As far as I can tell there are 6 scenarios: microseconds not replaced
microseconds replaced
Are all of these scenarios correct? The only non-obvious situation I guess is that not passing any value for |
@deshraj yeah sorry I've been sick for a little while now, I'll try to fix it ASAP when I can |
No worries. Take care. :) Happy to help if needed. |
UPDATING.md
Outdated
The default behavior was to strip the microseconds (and milliseconds, etc) off of all dag runs triggered by | ||
by the experimental REST API. The default behavior will change when an explicit execution_date is | ||
passed in the request body. It will also now be possible to have the execution_date generated, but | ||
keep the microseconds by sending `replace_microseconds: false` in the request body. The default |
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.
keep the microseconds by sending `replace_microseconds: false` in the request body. The default | |
keep the microseconds by sending `replace_microseconds=false` in the request body. The default |
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.
👍 fixed
UPDATING.md
Outdated
by the experimental REST API. The default behavior will change when an explicit execution_date is | ||
passed in the request body. It will also now be possible to have the execution_date generated, but | ||
keep the microseconds by sending `replace_microseconds: false` in the request body. The default | ||
behavior can be overridden by sending `replace_microseconds: true` along with an explicit 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.
behavior can be overridden by sending `replace_microseconds: true` along with an explicit execution_date | |
behavior can be overridden by sending `replace_microseconds=true` along with an explicit 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.
👍 fixed
oh no... that was not a successful rebase |
Enable the caller of the trigger_dag API endpoint to specify a boolean value for replace_microseconds. When false, this will store microseconds in the database for the execution_id, thus allowing more than 1 request per second to be processed by the REST API
No need to require a user to pass in replace_microseconds to the request body; instead we should use exactly the date that is given. We will still replace the microseconds on execution_date if none is passed in (and the param is True, which is the default)
A user can now choose to pass the execution_date in but still have the microseconds replaced by also sending replace_microseconds=true in the request body
1e8452d
to
3b3d9fc
Compare
UPDATING.md
Outdated
keep the microseconds by sending `replace_microseconds=false` in the request body. The default | ||
behavior can be overridden by sending `replace_microseconds=true` along with an explicit execution_date | ||
|
||
### Additional arguments passed to BaseOperator cause an exception |
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.
Looks like you've got some other changes included here?
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 apparently? I guess when rebasing somehow picked up extra commits
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.
fixed
The only way that replace_microseconds should be accessible is through the endpoints, so leave the testing there
@ashb may I ask you about the release timeline for this feature? |
@deshraj It will be in 1.10.7 which in ~1-2 months. |
… trigger_dag REST API (apache#6380) No need to require a user to pass in replace_microseconds to the request body; instead we should use exactly the date that is given. We will still replace the microseconds on execution_date if none is passed in (and the param is True, which is the default) (cherry picked from commit a45a209)
… trigger_dag REST API (#6380) No need to require a user to pass in replace_microseconds to the request body; instead we should use exactly the date that is given. We will still replace the microseconds on execution_date if none is passed in (and the param is True, which is the default) (cherry picked from commit a45a209)
… trigger_dag REST API (#6380) No need to require a user to pass in replace_microseconds to the request body; instead we should use exactly the date that is given. We will still replace the microseconds on execution_date if none is passed in (and the param is True, which is the default) (cherry picked from commit a45a209)
… trigger_dag REST API (#6380) No need to require a user to pass in replace_microseconds to the request body; instead we should use exactly the date that is given. We will still replace the microseconds on execution_date if none is passed in (and the param is True, which is the default) (cherry picked from commit a45a209)
Make sure you have checked all steps below.
Jira
Description
Reads the value for
replace_microseconds
from the API'strigger_dag
endpoint. This will allow the endpoint to trigger > 1 dag per second.Tests
TestApiExperimental.test_trigger_dag_for_date_with_replace_microseconds_false
Commits
Documentation