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

fix: ignore non-number value on BaseBoundInstrument.update #1366

Merged
merged 12 commits into from
Aug 20, 2020

Conversation

legendecas
Copy link
Member

Which problem is this PR solving?

  • OpenTelemetry can be used with pure JavaScript, there will be no build-time errors on writing counter.add(undefined) or counter.add({ arbitrary: 'value' }). Hence those aggregators conforming to the type interface Aggregator may receive non-number value on Aggregator.update.

Short description of the changes

  • Skip the value update if the value if not typed with number on BaseBoundInstrument.update.

@codecov
Copy link

codecov bot commented Jul 29, 2020

Codecov Report

Merging #1366 into master will decrease coverage by 0.09%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1366      +/-   ##
==========================================
- Coverage   93.89%   93.80%   -0.10%     
==========================================
  Files         148      144       -4     
  Lines        4393     4276     -117     
  Branches      894      869      -25     
==========================================
- Hits         4125     4011     -114     
+ Misses        268      265       -3     
Impacted Files Coverage Δ
...kages/opentelemetry-metrics/src/BoundInstrument.ts 100.00% <100.00%> (ø)
...ackages/opentelemetry-exporter-jaeger/src/types.ts
...ckages/opentelemetry-exporter-jaeger/src/jaeger.ts
...ackages/opentelemetry-exporter-jaeger/src/utils.ts
...ges/opentelemetry-exporter-jaeger/src/transform.ts

@@ -374,6 +375,63 @@ describe('Meter', () => {
assert.strictEqual(record1.aggregator.toPoint().value, 20);
assert.strictEqual(boundCounter, boundCounter1);
});

it('should trunk non-integer values for INT valueType', async () => {
Copy link
Member

Choose a reason for hiding this comment

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

what do you mean by "trunk" here?

Copy link
Member

Choose a reason for hiding this comment

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

Most likely trunc or truncate. @legendecas Please avoid abbreviations.

Copy link
Member

Choose a reason for hiding this comment

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

ignore then ?

Copy link
Member

Choose a reason for hiding this comment

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

No, it's a typo and it should be fixed, and the other cases should be made into their own tests.

Suggested change
it('should trunk non-integer values for INT valueType', async () => {
it('should truncate floating number values for INT valueType', async () => {

valueType: ValueType.INT,
});
const boundCounter = upDownCounter.bind(labels);
{
Copy link
Member

Choose a reason for hiding this comment

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

why extra brackets are needed here and in few other places ? If you want to separate cases perhaps it's a moment where it should go into separate unit test or simply make an array of values to test and then use a loop to test each value

Copy link
Member

Choose a reason for hiding this comment

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

The brackets give lexical scope to the const [record1] = meter.getBatcher().checkPointSet(); line. It is repeated several times in the test so that different values may be tested.

These should be separate tests as they are not all testing truncation

@legendecas
Copy link
Member Author

@dyladan @obecny updated, PTAL :D

@dyladan
Copy link
Member

dyladan commented Aug 19, 2020

@obecny @vmarchaud looks like your concerns have been addressed?

@dyladan dyladan added the enhancement New feature or request label Aug 20, 2020
@dyladan dyladan merged commit a576c3f into open-telemetry:master Aug 20, 2020
@legendecas legendecas deleted the non-number-update branch August 23, 2020 08:43
pichlermarc pushed a commit to dynatrace-oss-contrib/opentelemetry-js that referenced this pull request Dec 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants