Closed dlamotte closed 4 months ago
Hi @dlamotte, thank you for the report. I'll investigate.
Can you post your SDK configuration?
@cwaldren-ld I think you want this?
import (
...
ld "github.com/launchdarkly/go-server-sdk/v7"
)
var config ld.Config
{
if conf := flags.options.Config; conf != nil {
config = ld.Config{
DataSource: ldfiledata.DataSource().
FilePaths(*conf).
Reloader(ldfilewatch.WatchFiles),
Events: ldcomponents.NoEvents(),
}
} else {
config = ld.Config{
DataSource: ldcomponents.StreamingDataSource().InitialReconnectDelay(5 * time.Second),
Offline: false,
}
}
config.DiagnosticOptOut = true
}
config.Logging = ldcomponents.Logging().MinLevel(ldlog.Error)
client, err := ld.MakeCustomClient(apikey, config, 5*time.Second)
It's a partial. Hopefully its enough.
Appears fixed by https://github.com/launchdarkly/go-server-sdk/pull/151 (looks like there is another follow-on PR, but best follow those PRs)
This has been released as part of https://github.com/launchdarkly/go-server-sdk/releases/tag/v7.4.1
Is this a support request?
No.
Describe the bug
https://github.com/launchdarkly/go-server-sdk/blob/v7/internal/broadcasters.go#L70 accesses
b.subscribers
without guarding the access with a mutex.To reproduce
go test -race
You might need-count=100
. Our units running with-race -count=100
routinely fail here.Expected behavior No data races.
Logs
...
redacted aspects of our codebase as they are not important.SDK version
Language version, developer tools
go version go1.21.4 darwin/arm64
OS/platform OSX.
Additional context Impact is that we cannot use
-race
when running our unit tests to find races. So we have to have two unit test runs until this is fixed which is not ideal as we actually had a data race in our code on top of this code. So, I'd prefer to eliminate this race so we can ensure we don't have races in our code.