Open chahatsagarmain opened 1 week ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 48.76%. Comparing base (
2b7cf3a
) to head (ee64cb4
). Report is 11 commits behind head on main.:exclamation: There is a different number of reports uploaded between BASE (2b7cf3a) and HEAD (ee64cb4). Click for more details.
HEAD has 1 upload less than BASE
| Flag | BASE (2b7cf3a) | HEAD (ee64cb4) | |------|------|------| |unittests|1|0|
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
🚨 Try these New Features:
Have you observe this new test fail? It doesn't look like it's testing race condition deterministically.
Have you observe this new test fail? It doesn't look like it's testing race condition deterministically.
In the previous test, the race condition occurred because the mutex was not used. Adding the mutex resolved the issue. However, in the updated test, new TLS configurations are being applied and its seems to be causing data race during client connection and TLS handshake error .
so I see this test is failing on detected race condition, but the stack traces indicate that the race is caused by the test itself (the Write part), not by the production code:
WARNING: DATA RACE
Write at 0x00c000138400 by goroutine 163:
github.com/jaegertracing/jaeger/pkg/config/tlscfg.TestCertificateRaceCondition.func4()
/home/runner/work/jaeger/jaeger/pkg/config/tlscfg/options_test.go:392 +0xdc
Previous read at 0x00c000[138](https://github.com/jaegertracing/jaeger/actions/runs/11900851926/job/33162577763?pr=6213#step:8:139)400 by goroutine 162:
github.com/jaegertracing/jaeger/pkg/config/tlscfg.(*Options).Config()
/home/runner/work/jaeger/jaeger/pkg/config/tlscfg/options.go:75 +0x676
@chahatsagarmain an alternative to fixing the race condition from reloading is to eliminate the use of this package altogether. We already migrated several endpoints to use OTEL helpers which internally handle TLS reloading differently (on a timeout rather than on file change). It would be interesting to see which parts of Jaeger still use the tlscfg
package and switch to OTEL helpers.
@yurishkuro So i can use configtls
from OTEL and replace the usage of the tlscfg
package ?
Also , there is usage of tlscfg
in collector and agent and mostly test files .
yes, that would be good. You can start small, e.g. can we remove tlscfg
dependency from cmd/es-rollover
?
Which problem is this PR solving?
Description of the changes
How was this change tested?
Checklist
jaeger
:make lint test
jaeger-ui
:yarn lint
andyarn test