-
Notifications
You must be signed in to change notification settings - Fork 75
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
Feat: Instrument await using await-tree #669
Conversation
@iGxnon I'm not sure if these are the correct changes that you were looking for, right now I have just added Also, I'll fix the DCO. |
It seems that some validations are not passing. Please check your code and provide an example output if possible. |
Sure, I'll report back with some output. Thanks for the help! |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #669 +/- ##
==========================================
- Coverage 74.55% 74.52% -0.04%
==========================================
Files 172 172
Lines 25288 25342 +54
Branches 25288 25342 +54
==========================================
+ Hits 18854 18886 +32
- Misses 5263 5287 +24
+ Partials 1171 1169 -2 ☔ View full report in Codecov by Sentry. |
@iGxnon Sorry for not being able to devote my time properly for this issue, was busy with some stuff. From what I can see, I'm failing the codecov/project check. Could you suggest some changes that I could make to pass the test? |
Hello, @Harsh1s! I pulled down this pr and found that the signed-off-by information was lost. That's the reason behind the DCO failure. I recommend rebasing your pr on the latest commit of the master branch instead of merging them directly. |
Hello there @Phoenix500526 , apologies for accidently closing this PR while fixing the DCO. I opened a new PR instead of this one. I'll take care of rebasing from next time. Thanks! |
Signed-off-by: Harsh Raj [email protected]
what problem are you trying to solve? (or if there's no problem, what's the motivation for this change?)
-> FIxes [Feature]: Instrument the execution path of the command (i.e.
fast_path
orslow_path
) #580-> Currently, some simple information is logged to display the execution path of the command. This uses more detailed information to show this process (i.e. use await-tree to indicate the duration of each await.).
what changes does this pull request make?
-> Makes use of
instrument_await
within functions annotated with the #[instrument] macro to add more detailed async tracing.are there any non-obvious implications of these changes? (does it break compatibility with previous versions, etc)
-> No