Skip to content

Conversation

@trentm
Copy link
Contributor

@trentm trentm commented Aug 21, 2024

Before this change an instrumentation instance's config, as returned
from .getConfig(), would include {enabled: true} after construction,
new MyInstrumentation(); but would not include 'enabled' after
.setConfig({}). That inconsistency could cause bugs in usage of
this.getConfig().enabled.

…efaulting to true

Before this change an instrumentation instance's config, as returned
from .getConfig(), would include {enabled: true} after construction,
`new MyInstrumentation()`; but would not include 'enabled' after
`.setConfig({})`. That inconsistency could cause bugs in usage of
`this.getConfig().enabled`.
trentm added a commit to david-luna/opentelemetry-js-contrib that referenced this pull request Aug 21, 2024
…s this._enabled state can be maintained; explain some of the confusion with enabled state handling in InstrumentationBase and go back to using config.enabled to decide whether to generate instrumentation

One tweak on using config.enabled is that I'm checking `!== false` in
case the config object doesn't have "enabled" defined -- currently
possible if `instr.setConfig({})` is called. I opened
open-telemetry/opentelemetry-js#4941 for that.
@pichlermarc pichlermarc added this pull request to the merge queue Aug 22, 2024
Merged via the queue into open-telemetry:main with commit 0ee398d Aug 22, 2024
@trentm trentm deleted the tm-instr-setConfig-should-set-enabled branch August 22, 2024 15:24
Zirak pushed a commit to Zirak/opentelemetry-js that referenced this pull request Sep 14, 2024
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.

2 participants