Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Ensure triggering of callback in chord #397
base: main
Are you sure you want to change the base?
Ensure triggering of callback in chord #397
Changes from 1 commit
6e0aa80
90344aa
5c6b5df
1b04c88
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 this is correct, we have a header of 2, 1 is done, the other fails.
If a task in the header fails the chord is done and the callback is not called.
If this is the case, a ChordCounter object will remain in the db for every failed chord.
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.
@AllexVeldman but if you have retry logic (on code or worker level) all task eventually are successful, but the callback is never triggered.
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.
https://docs.celeryq.dev/en/latest/reference/celery.result.html#celery.result.AsyncResult.ready would suggest
deps.ready()
would be False in case of a retry, True in case of a failure like in this test.So this test should call the path all the way to
trigger_callback()
and fail the Chord, otherwise a Chord can never fail.It suprises me that this is not the case with your proposed changes, since
trigger_callback
should beTrue
,deps.ready()
should beTrue
so bothtrigger_callback()
andchord_counter.delete()
should have been called.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, it took some time but I figured out why this change makes the test pass (which is still not correct).
It's because the MagicMock used for the
request
parameter tomark_as_done()
andmark_as_failure()
does not haveignore_result = False
set. This in turn would makerequest.ignore_result
evaluate toTrue
, skipping saving the result, which is needed to havedeps.ready()
work properly. Since we did not rely ondeps.ready()
in the previous state this never surfaced as an issue.Add
ignore_result = False
to the MagicMock and reverting the test changes will fix the test.