-
Notifications
You must be signed in to change notification settings - Fork 1.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
Add Tracing to Identity #5019
Add Tracing to Identity #5019
Conversation
@@ -86,6 +89,9 @@ export class IdentityClient extends ServiceClient { | |||
return null; | |||
} | |||
|
|||
const span = createSpan("IdentityClient-refreshAccessToken", getSpanOptions(options)); |
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.
Where is this span name convention coming from? Is this aligning with other languages?
} catch (err) { | ||
if (err instanceof AuthenticationError && err.errorResponse.error === "interaction_required") { | ||
span.end(); |
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'd put span.end() in a finally block rather than in both the try and catch legs.
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 would work if the catch
block was not throwing the error again like it does here
@@ -0,0 +1,37 @@ | |||
// Copyright (c) Microsoft Corporation. |
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.
Should these helpers move to some core library?
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.
The getSpanOptions
is not required. A call to this can be replaced with options && options.spanOptions
The createSpan
can indeed move to core-tracing
, but I would keep work out of this PR.
const tracer = TracerProxy.getTracer(); | ||
const span = tracer.startSpan(name, spanOptions); | ||
if (tracer.pluginType !== SupportedPlugins.NOOP && (spanOptions && spanOptions.parent)) { | ||
spanOptions = { ...spanOptions, parent: span }; |
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.
This will only update the local variable spanOptions
and not the actual spanOptions
on the outer options of type GetTokenOptions
which is what we want right?
Updating the local variable serves no purpose.
I would suggest the below
- Update
createSpan
to take options of typeGetTokenOptions
as the second parameter - Then the above line would become
options.spanOptions = { ...options.spanOptions, parent: span };
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.
On second thoughts, I realize that updating the parent
on the spanOptions might not be a good idea to do inside createSpan
.
There are cases in this PR where we pass the same options (of type GetTokenOptions
) to multiple methods which internally create more spans. Having the options updated inside createSpan
will mess these parallel calls that are happening.
Essentially, we might have to clone the options each time it gets passed around.
abortSignal: options && options.abortSignal, | ||
spanOptions: { | ||
parent: span | ||
} |
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.
Here, we are assuming that parent
is the only thing we want to care about in span options.
The customer might be using a tracer that would take in more items in the options bag. The customer might have provided that, but we end up ignoring it 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.
@sarangan12 I have taken a look at most files and my main feedback is around updating createSpan
to take the GetTokenOptions
to avoid setting the parent outside of createSpan
.
Please take a look if that is doable. Also, I have the PR #5055 out to format the files in identity. Hopefully we can have that merged first and then update your branch from master. This way, we can remove all the formatting noise out of this PR
…azure-sdk-for-js into AddTracingToIdentity
@@ -8,7 +8,9 @@ dependencies: | |||
'@azure/ms-rest-js': 2.0.4 | |||
'@azure/ms-rest-nodeauth': 0.9.3 | |||
'@azure/storage-blob': 12.0.0-preview.2 | |||
'@microsoft/api-extractor': 7.3.8 | |||
'@microsoft/api-extractor': 7.3.11 |
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.
Was this file updated by running rush update
or rush update --full
? It appears to be the latter, since unrelated dependencies are being updated. Can you please revert this file and run rush update
to just add/update the dependencies modified in this PR?
@@ -80,6 +80,9 @@ | |||
}, | |||
"devDependencies": { | |||
"@azure/abort-controller": "1.0.0-preview.2", | |||
"@opencensus/core": "~0.0.17", |
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.
Most dependencies should use ^
. Is there a reason these new dependencies use ~
instead?
* @param options options to be modified | ||
*/ | ||
|
||
export function modifySpanOptions(span: Span, options?: GetTokenOptions): GetTokenOptions { |
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.
Really this isn't modifying span options so much as it is creating a new span options for the child span manufactured in createSpan.
Since this method always gets called after createSpan, would it make more sense to have createSpan return an object of { span, options } so you can destructure the result and not need to call two methods each time?
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.
Yes, please. I was about to make a similar suggestion in another place in this PR. I think it's inconvenient to always have to call two methods, and also possibly easy to forget.
1, | ||
`Number of children ${rootSpan.numberOfChildren} is not equal to 1.` | ||
); | ||
const numberOfDescendants = rootSpan.allDescendants().length; |
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.
Should we add some kind of validator for the rootSpan that can understand more than just the child count / descendant count?
In chromium we'd use golden files for this and write out all the events with things like timestamps sanitized, but maybe in this case we could just have a helper function that takes a tree-like structure of the expected events?
@@ -32,6 +33,10 @@ export class ChainedTokenCredential implements TokenCredential { | |||
let token = null; | |||
const errors = []; | |||
|
|||
const span = createSpan("ChainedTokenCredential-getToken", options); | |||
options = modifySpanOptions(span, options); |
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.
nit: personally, I think it's bad form to mutate function parameters. I prefer to treat them as immutable and create new local versions when necessary.
Superceded this PR with #5283 |
I have made changes to core-http, core-auth & identity. I have not updated any package versions. Will discuss with Ramya and update package versions on Monday