Skip to content
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

Closed
wants to merge 12 commits into from
Closed

Conversation

sarangan12
Copy link
Contributor

@sarangan12 sarangan12 commented Sep 5, 2019

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

@sarangan12 sarangan12 changed the title Add Tracing to Identity - WIP - OK for Initial Review Add Tracing to Identity Sep 6, 2019
@@ -86,6 +89,9 @@ export class IdentityClient extends ServiceClient {
return null;
}

const span = createSpan("IdentityClient-refreshAccessToken", getSpanOptions(options));
Copy link
Member

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();
Copy link
Member

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.

Copy link
Contributor

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.
Copy link
Member

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?

Copy link
Contributor

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 };
Copy link
Contributor

@ramya-rao-a ramya-rao-a Sep 8, 2019

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 type GetTokenOptions as the second parameter
  • Then the above line would become options.spanOptions = { ...options.spanOptions, parent: span };

Copy link
Contributor

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
}
Copy link
Contributor

@ramya-rao-a ramya-rao-a Sep 8, 2019

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.

Copy link
Contributor

@ramya-rao-a ramya-rao-a left a 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

@sarangan12 sarangan12 requested a review from daviwil as a code owner September 8, 2019 21:18
@@ -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
Copy link
Member

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",
Copy link
Member

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 {
Copy link
Member

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?

Copy link
Contributor

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;
Copy link
Member

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);
Copy link
Member

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.

@xirzec xirzec mentioned this pull request Sep 27, 2019
5 tasks
@xirzec
Copy link
Member

xirzec commented Sep 27, 2019

Superceded this PR with #5283

@xirzec xirzec closed this Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants