Closed jspri closed 1 year ago
Found using the go race detector. Using an atomic for the initialized check/set is probably the easiest fix.
I assume all methods of the SDK are intended to be thread safe.
WARNING: DATA RACE Read at 0x00c000e865bc by goroutine 97: gopkg.in/launchdarkly/go-server-sdk.v5/internal/datasource.(*StreamProcessor).IsInitialized() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/internal/datasource/streaming_data_source.go:108 +0x37 gopkg.in/launchdarkly/go-server-sdk%2ev5.(*LDClient).Initialized() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/ldclient.go:497 +0x156 gopkg.in/launchdarkly/go-server-sdk%2ev5.(*LDClient).evaluateInternal() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/ldclient.go:881 +0x159 gopkg.in/launchdarkly/go-server-sdk%2ev5.(*LDClient).variation() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/ldclient.go:827 +0x237 gopkg.in/launchdarkly/go-server-sdk%2ev5.(*LDClient).BoolVariation() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/ldclient.go:620 +0x23e Previous write at 0x00c000e865bc by goroutine 240: gopkg.in/launchdarkly/go-server-sdk.v5/internal/datasource.(*StreamProcessor).setInitializedAndNotifyClient.func1() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/internal/datasource/streaming_data_source.go:334 +0x124 sync.(*Once).doSlow() C:/Users/justin/sdk/go1.17.5/src/sync/once.go:68 +0x127 sync.(*Once).Do() C:/Users/justin/sdk/go1.17.5/src/sync/once.go:59 +0x46 gopkg.in/launchdarkly/go-server-sdk.v5/internal/datasource.(*StreamProcessor).setInitializedAndNotifyClient() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/internal/datasource/streaming_data_source.go:332 +0x67 gopkg.in/launchdarkly/go-server-sdk.v5/internal/datasource.(*StreamProcessor).consumeStream() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/internal/datasource/streaming_data_source.go:184 +0x47d gopkg.in/launchdarkly/go-server-sdk.v5/internal/datasource.(*StreamProcessor).subscribe() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/internal/datasource/streaming_data_source.go:327 +0x705 gopkg.in/launchdarkly/go-server-sdk.v5/internal/datasource.(*StreamProcessor).Start·dwrap·8() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/internal/datasource/streaming_data_source.go:117 +0x47 Goroutine 97 (running) created at: net/http.(*Server).Serve() C:/Users/justin/sdk/go1.17.5/src/net/http/server.go:3034 +0x847 Goroutine 240 (running) created at: gopkg.in/launchdarkly/go-server-sdk.v5/internal/datasource.(*StreamProcessor).Start() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/internal/datasource/streaming_data_source.go:117 +0x2a7 gopkg.in/launchdarkly/go-server-sdk%2ev5.MakeCustomClient() C:/Users/justin/go/pkg/mod/gopkg.in/launchdarkly/go-server-sdk.v5@v5.6.0/ldclient.go:280 +0x2068
Thank you for the report @jspri, we'll investigate this.
Filed internally as 145356.
Closing this as fixed by 5.10.0.
Found using the go race detector. Using an atomic for the initialized check/set is probably the easiest fix.
I assume all methods of the SDK are intended to be thread safe.