coveralls
commented
3 years ago Pull Request Test Coverage Report for Build 3ba6deea-18e8-4f67-bcbb-9f4ff8d5c42d
- 7 of 8 (87.5%) changed or added relevant lines in 1 file are covered.
- 11 unchanged lines in 2 files lost coverage.
- Overall coverage increased (+0.1%) to 71.219%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
|---|---|---|---|---|---|
| internal/internal_event_handlers.go | 7 | 8 | 87.5% | ||
| <!-- | Total: | 7 | 8 | 87.5% | --> |
| Files with Coverage Reduction | New Missed Lines | % | ||
|---|---|---|---|---|
| internal/common/convert.go | 3 | 84.62% | ||
| internal/internal_task_pollers.go | 8 | 80.96% | ||
| <!-- | Total: | 11 | --> |
| Totals | |
|---|---|
| Change from base Build 6e7ee6fa-6a5e-4c8b-b873-e06b32984d79: | 0.1% |
| Covered Lines: | 12093 |
| Relevant Lines: | 16980 |
demirkayaender
What changed? Server performs timer duration validation against duration in seconds. However, client performs the same checks against duration type. Although, the client side checks look safe enough, we had a recent incident where server received invalid timer parameters. Although it's unlikely, this validation discrepancy probably happened due to the float to int conversion discrepancies. Therefore, we are applying the same type of validation in client to eliminate that possibility.
Why?
How did you test it?
Potential risks