-
Notifications
You must be signed in to change notification settings - Fork 2
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
return_progress as arg for run_query #601
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #601 +/- ##
==========================================
+ Coverage 60.96% 61.21% +0.25%
==========================================
Files 47 48 +1
Lines 8472 8548 +76
==========================================
+ Hits 5165 5233 +68
- Misses 3307 3315 +8 ☔ View full report in Codecov by Sentry. |
An additional boolean argument for the In this way, each plugin can behave differently if the return_progress is passed as True. Is this what you had in mind @volodymyrss ? |
something like that, we need to try interface with test plugin, and of course preserve existing behavior |
Adding the arg EDIT I am using a different approach |
cdci_data_analysis/plugins/dummy_plugin/empty_async_return_progress_instrument.py
Fixed
Show fixed
Hide fixed
cdci_data_analysis/plugins/dummy_plugin/empty_async_return_progress_instrument.py
Fixed
Show fixed
Hide fixed
I keep seeing this error from the oda_api run:
I investigated a lot but still it is to me completely unclear why it happens |
By checking out a specific branch from the |
Could you maybe add more logging to enable this? |
I think I have it figured out, finally. When running the The other test to fail is This invalid token is discovered within the environment by the oda_api, and then sent to the production dispatcher, which, obviously fails, since it is signed with the test secret key. The tests run before A dedicated PR will address this |
But why have this error appeared in this PR only? |
maybe the order of tests is changing?.. it's not guaranteed to be always the same. |
interesting! Indeed, each test env variables should be strickly controlled, all set before the test. |
The test But the clean-up does not happen and therefore |
It took quite some debugging...and a bit of imagination |
exactly, I discovered because I made the assumption that such order was followed...but just in this instance. it's not always like that |
It's best to never rely on tests to clean-up anything. Instead, clean environment should be created before the test. |
tests can even be run in parallel, so no way to guarantee order. |
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.
test fails
The test |
right, well, this PR will wait for the fix then. |
tests passing now |
No description provided.