Skip to content
This repository has been archived by the owner on Oct 3, 2023. It is now read-only.

refactor: address opencensus-core TODOs #47

Merged

Conversation

eduardoemery
Copy link
Contributor

No description provided.

@googlebot
Copy link

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

@@ -27,9 +27,6 @@ export class ConsoleLogger implements types.Logger {
static LEVELS = ['silent', 'error', 'warn', 'info', 'debug', 'silly'];
level: string;


// TODO: reevaluate options to accept numbers as a parameter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For each TODO that is removed without changes, please document (as a PR comment) why you decided not to do it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll comment those. This one in specific was removed because being able to use numbers as parameters gives more freedom to the end user. Also, passing number as parameters is being currently used across the implementation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, thanks.

@@ -25,7 +25,8 @@ export interface Exporter extends modelTypes.SpanEventListener {
* Sends a list of root spans to the service.
* @param rootSpans A list of root spans to publish.
*/
publish(rootSpans: modelTypes.RootSpan[]): void;
// tslint:disable-next-line:no-any
publish(rootSpans: modelTypes.RootSpan[]): Promise<any>|void;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two notes:

  1. What is the meaning of the deferred value being returned here? How are users expected to treat this value? If there are no good answers to this question it should just be Promise<void>.
  2. Returning either a Promise or void complicates handling the return value. Can we only return Promise?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ideia is that by returning Promise<any> | void we account for publish methods that returns a Promise, while giving freedom to future collaborators to make a method that returns void. Currently, NoopExporter and ConsoleExporter return void, but if you prefer, I can change them to return Promise<void> and restrict the interface, no problems with that IMO.

Copy link
Contributor

@kjin kjin Jun 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's OK for publish to inherently not contain anything asynchronous, but it would still be more consistent to return a Promise.resolve() instead of void anyway. If we consider the code that will call this function:

const result = exporter.publish();
if (result) {
  result.then(next);
} else {
  next(); // note: zalgo alert
}

Why even have this branching logic, when we could just do

exporter.publish().then(next);

That was the original context behind the second question. If you could make the change in *Exporter that would be great.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, got it. Made the change but had to make Promise<number|string|void> to account for some exporter implementations that resolve number or string.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Promise<number|string|void> goes back to my original first question. Do we use the return value in a meaningful way? If so, it would be better to standardize now what that return value is (maybe a boolean or status code). Otherwise, if we don't use it, we should just make it void.

BTW, the answer to this question might not exist today. It's hard to know how to standardize the return value if we are currently not using it. So I can merge this PR, just something to think about.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could see the return value being used in tests only, but not in applications. I'm not sure if we should standardize it tho, goes back to that thing about future contributors. But I understand your point of view. Would be great to discuss that latter.

*/
abstract applyPatch(
// tslint:disable:no-any
moduleExports: any, tracer: modelTypes.Tracer, version: string): any;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we are here... maybe it makes sense to parameterize the return value. We know the moduleExports and the return value should be the same type, so we can make it applyPatch<T>(moduleExports: T, ...): T;.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes a lot of sense. As oc-core changed since this PR was opened, I made this change to the enable method.

"ts-node": "^4.0.0",
"typescript": "~2.6.1",
"nyc": "11.6.0"
"intercept-stdout": "^0.1.2",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you preserve the alphabetical ordering here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

@@ -104,10 +101,6 @@ export class ConsoleLogger implements types.Logger {
}
}


// TODO: reevaluate the need to create a new logger instance on every call to
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By creating a new logger instance on every call to it we allow distinct classes to have distinct log levels.

Copy link
Contributor

@kjin kjin Jun 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the original comment that this was in reference to is that every time logger was called, the field logger['logger'] was being replaced. This field is also never getting read. The logger method is otherwise just a call-through to new ConsoleLogger.

I would prefer that logger not even exist in the first place, and that anywhere it's used, new ConsoleLogger is used instead. After all, why do we need the wrapper method?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My mistake, I got the TODO confused. Regarding this one, our idea here is to return an instance of logger, although calling new ConsoleLogger() works too. We drove inspiration from this logDriver.

I removed the logger['logger'] = aLogger; that had no need to be there at all.

@@ -19,9 +19,6 @@

import * as crypto from 'crypto';


// TODO: rethink this snippet aproach
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was no need for change here.

Copy link
Contributor

@kjin kjin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some replies, what do you think?

@eduardoemery
Copy link
Contributor Author

Sorry for the delay. Took a look at your comments, thanks for reviewing. Made a few changes.

@eduardoemery eduardoemery force-pushed the refactor_address_core_TODOs branch 3 times, most recently from 394a12d to f807861 Compare June 21, 2018 16:46
@kjin
Copy link
Contributor

kjin commented Jun 21, 2018

@eduardoemery Maybe you're in the middle of it right now, but currently the review comment changes only include package-lock.json. Did you miss adding a file to the commit?

@eduardoemery eduardoemery force-pushed the refactor_address_core_TODOs branch 2 times, most recently from d94f3ad to e044058 Compare June 22, 2018 10:57
@eduardoemery
Copy link
Contributor Author

Yesterday morning I had some trouble with my git. Got it fixed but apparently it impacted here. Fixed now, sorry for the trouble caused.

const aLogger = new ConsoleLogger(options);
logger['logger'] = aLogger;
return aLogger;
return new ConsoleLogger(options);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Make this function have return type ConsoleLogger

Copy link
Contributor Author

@eduardoemery eduardoemery Jun 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I used the interface types.Logger instead of ConsoleLogger to keep the pattern of using interfaces. But let me know if you don't agree.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

types.Logger is better. Thanks!

@googlebot
Copy link

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

@kjin kjin removed the cla: no label Jun 22, 2018
@kjin kjin merged commit db46f4f into census-instrumentation:master Jun 22, 2018
kjin pushed a commit to kjin/opencensus-node that referenced this pull request Aug 24, 2018
* refactor: changes to address opencensus-core TODOs

* refactor: reveiw TODO for clearCurrentTrace when using continuation-local-storage

* refactor(fix): changes to address review comments

Co-authored-by: Fabio Silva <fgs@cesar.org.br>
kjin pushed a commit to kjin/opencensus-node that referenced this pull request Aug 24, 2018
* refactor: changes to address opencensus-core TODOs

* refactor: reveiw TODO for clearCurrentTrace when using continuation-local-storage

* refactor(fix): changes to address review comments

Co-authored-by: Fabio Silva <fgs@cesar.org.br>
kjin pushed a commit to kjin/opencensus-node that referenced this pull request Aug 24, 2018
* refactor: changes to address opencensus-core TODOs

* refactor: reveiw TODO for clearCurrentTrace when using continuation-local-storage

* refactor(fix): changes to address review comments

Co-authored-by: Fabio Silva <fgs@cesar.org.br>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants