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

chore: cleanup setting config in instrumentations #2522

Merged
merged 7 commits into from
Oct 27, 2021

Conversation

Flarna
Copy link
Member

@Flarna Flarna commented Oct 6, 2021

Short description of the changes

There is no need to create a copy of the config object as this is done in base class.
Remove defaulting to an empty config object at several places as this is done in the base class.
Remove the intersection type with InstrumentationConfig as all config types extend this type.
Avoid overriding the _config property in the grpc instrumentation.

There is no need to create a copy of the config object as this is done in base class.
Remove defaulting to an empty config object at several places as this is done in the base class.
Remove the intersection type with InstrumentationConfig as all config types extend this type.
Avoid overriding the _config property in the grpc instrumentation.
@Flarna Flarna requested a review from a team October 6, 2021 09:46
@codecov
Copy link

codecov bot commented Oct 6, 2021

Codecov Report

Merging #2522 (1e19790) into main (c0ab952) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #2522      +/-   ##
==========================================
- Coverage   93.07%   93.07%   -0.01%     
==========================================
  Files         140      140              
  Lines        5172     5169       -3     
  Branches     1111     1101      -10     
==========================================
- Hits         4814     4811       -3     
  Misses        358      358              
Impacted Files Coverage Δ
...emetry-instrumentation-grpc/src/instrumentation.ts 75.86% <0.00%> (-0.81%) ⬇️
...elemetry-instrumentation-grpc/src/grpc-js/index.ts 90.72% <0.00%> (-0.10%) ⬇️
...entelemetry-instrumentation-grpc/src/grpc/index.ts 92.98% <0.00%> (-0.07%) ⬇️
...ges/opentelemetry-instrumentation-http/src/http.ts 94.90% <0.00%> (ø)
...emetry-instrumentation-xml-http-request/src/xhr.ts 97.58% <0.00%> (ø)

Copy link
Member

@obecny obecny left a comment

Choose a reason for hiding this comment

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

I would add few other refactoring to have real typed getConfig

@@ -125,6 +116,10 @@ export class GrpcJsInstrumentation extends InstrumentationBase {
];
}

override getConfig(): GrpcInstrumentationConfig {
Copy link
Member

Choose a reason for hiding this comment

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

are you overriding this just to have correct type, if so I would rather do it differently by refactoring abstract class - something like this

export abstract class InstrumentationAbstract<T = types.InstrumentationConfig>
  implements types.Instrumentation {
  protected _config: T;
  constructor(
    public readonly instrumentationName: string,
    public readonly instrumentationVersion: string,
    config: T

It would require small refactoring of init method as well as InstrumentationModuleDefinition

export interface InstrumentationModuleDefinition<T = any> {

But then you would not have to worry about overriding the getConfig to have typed config from instrumentation class WDYT ?

Copy link
Member Author

@Flarna Flarna Oct 12, 2021

Choose a reason for hiding this comment

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

I tried that a while ago but failed. typescript complained at various places like

  • the different default arguments in constructor of the concrete instrumentations
  • no compatible base type for registerInstrumentation() arguments.

There is already a stalled PR from @dyladan regarding this: #2388

Copy link
Member

Choose a reason for hiding this comment

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

My stalled PR was stalled because it was more difficult to get typescript to be happy than I anticipated when I started it. For now, I think doing it this way is probably fine.

I would like to make the types smarter eventually. I know it should be possible if someone has the time and inclination.

@vmarchaud vmarchaud requested a review from obecny October 26, 2021 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants