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 a threshold for expected zero values in the SPM script #5753

Merged
merged 3 commits into from
Jul 17, 2024

Conversation

FlamingSaint
Copy link
Member

Which problem is this PR solving?

  • Makes sure the SPM CI doesn't fail if the first value received is zero.

Description of the changes

  • The script now waits until the threshold (Currently set to 3) number of zero values are received before throwing an error

How was this change tested?

  • Manually

Checklist

Signed-off-by: FlamingSaint <raghuramkannan400@gmail.com>
@FlamingSaint FlamingSaint requested a review from a team as a code owner July 16, 2024 17:14
@dosubot dosubot bot added the enhancement label Jul 16, 2024
Copy link

codecov bot commented Jul 16, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.66%. Comparing base (67ddb2c) to head (6a49726).

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #5753       +/-   ##
===========================================
+ Coverage   53.70%   96.66%   +42.95%     
===========================================
  Files         169      341      +172     
  Lines        8506    16451     +7945     
===========================================
+ Hits         4568    15902    +11334     
+ Misses       3495      361     -3134     
+ Partials      443      188      -255     
Flag Coverage Δ
badger_v1 8.05% <ø> (ø)
badger_v2 1.90% <ø> (ø)
cassandra-3.x-v1 16.61% <ø> (ø)
cassandra-3.x-v2 1.82% <ø> (ø)
cassandra-4.x-v1 16.61% <ø> (ø)
cassandra-4.x-v2 1.82% <ø> (ø)
elasticsearch-6.x-v1 18.77% <ø> (ø)
elasticsearch-7.x-v1 18.84% <ø> (ø)
elasticsearch-8.x-v1 19.02% <ø> (ø)
elasticsearch-8.x-v2 1.88% <ø> (ø)
grpc_v1 9.52% <ø> (ø)
grpc_v2 7.47% <ø> (ø)
kafka 9.74% <ø> (ø)
memory_v2 1.90% <ø> (ø)
opensearch-1.x-v1 18.88% <ø> (-0.02%) ⬇️
opensearch-2.x-v1 18.88% <ø> (ø)
opensearch-2.x-v2 1.90% <ø> (ø)
unittests 95.08% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@FlamingSaint FlamingSaint marked this pull request as draft July 16, 2024 17:28
Signed-off-by: FlamingSaint <raghuramkannan400@gmail.com>
@FlamingSaint FlamingSaint marked this pull request as ready for review July 16, 2024 17:32
Comment on lines 65 to 66
local non_zero_count=0
local threshold=3
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
local non_zero_count=0
local threshold=3
local non_zero_count=0
local expected_non_zero_count=3
local zero_count=0
local expected_max_zero_count=3

Copy link
Member

Choose a reason for hiding this comment

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

but tbh, I would consider deleting zero_count logic altogether. If zero values can be produced due to race conditions in the start-up, maybe we should only be looking for 3+ non-zero values and not worry about zeros.

If we still want to check for errors with a threshold, then it would make sense to only allow zeros at the beginning on the time series, once we start getting data I don't see a strong reason why zeros should show up again

Copy link
Member Author

@FlamingSaint FlamingSaint Jul 16, 2024

Choose a reason for hiding this comment

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

Yea makes sense, I think we can just wait for 3 non-zero values. Maybe timeout if we still haven't gotten 3 values ?

Copy link
Member

Choose a reason for hiding this comment

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

we already have the timeout logic handled. This function just checks if "in the current state" the data satisfies the requirements. And that requirement could be 0{0-3} >0{3+}, i.e. no more than 3 leading zeroes followed by at least 3 non-zeros.

Copy link
Member Author

Choose a reason for hiding this comment

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

Understood. I will make the changes.

Copy link
Member

Choose a reason for hiding this comment

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

@FlamingSaint I merged this for now to prevent spurious failures affecting other PRs, but let's make the change we discussed as a next improvement.

Signed-off-by: FlamingSaint <raghuramkannan400@gmail.com>
@yurishkuro yurishkuro added the changelog:ci Change related to continuous integration / testing label Jul 17, 2024
@yurishkuro yurishkuro merged commit 0e7f3f4 into jaegertracing:main Jul 17, 2024
43 of 44 checks passed
FlamingSaint added a commit to FlamingSaint/jaeger that referenced this pull request Jul 20, 2024
…cing#5753)

## Which problem is this PR solving?
- Makes sure the SPM CI doesn't fail if the first value received is
zero.

## Description of the changes
- The script now waits until the threshold (Currently set to 3) number
of zero values are received before throwing an error

## How was this change tested?
- Manually

## Checklist
- [x] I have read
https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md
- [x] I have signed all commits
- [ ] I have added unit tests for the new functionality
- [ ] I have run lint and test steps successfully
  - for `jaeger`: `make lint test`
  - for `jaeger-ui`: `yarn lint` and `yarn test`

---------

Signed-off-by: FlamingSaint <raghuramkannan400@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog:ci Change related to continuous integration / testing enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants