chore: fix data races

[nktks]

PR Checklist

• Read the Contributing documentation.
• Read the Code of conduct documentation.
• Name your Pull Request title clearly, concisely, and prefixed with the name of the primarily affected package you changed according to Good commit messages (such as memory: add interfaces for X, Y or util: add whizzbang helpers).
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. Fixes #123).
• Describes the source of new concepts. <- I don't add new concept
• References existing implementations as appropriate.
• Contains test coverage for new functions. <- I don't add new function
• Passes all golangci-lint checks.

What

Hello.
Thank you for maintaining this great module!
I would like to:

• fix OpenAI Chat LLM thread safety #281 (comment)
• add -race flag in go test CI to avoid data race.
• fix data race in test case https://github.com/tmc/langchaingo/actions/runs/12115516980/job/33774019172?pr=1080

[leventov]

There is at least one more race, ernieclient.Client.accessToken field is written in autoRefresh() through a race. This is pretty much a syntactically-catchable thing, I wonder why go vet or other tools don't catch this.

[nktks]

@leventov
Hello.
You mentioned about https://github.com/nktks/langchaingo/blob/fix/data-race/llms/ernie/internal/ernieclient/ernieclient.go#L178 ?

I think, the normal use case is to call ernieclient.New() only once for one *ernieclient.Client instance.
In this case, autoRefresh() is called only in ernieclient.New(), and the accessToken is written in only one goroutine in autoRefresh(), so rata races won't occur.

[leventov]

@nktks yes, only one goroutine. But isn't writing a plain field c.accessToken from one goroutine and then reading from others (any goroutines that use the Client for making LLM calls) a data race? Shouldn't such value hand over happen either via atomic.Value, or a channel, but not just plain field write/read?

[leventov]

Here's from https://go.dev/ref/mem:

Reads of memory locations larger than a single machine word are encouraged but not required to meet the same semantics as word-sized memory locations, observing a single allowed write w. For performance reasons, implementations may instead treat larger operations as a set of individual machine-word-sized operations in an unspecified order. This means that races on multiword data structures can lead to inconsistent values not corresponding to a single write. When the values depend on the consistency of internal (pointer, length) or (pointer, type) pairs, as can be the case for interface values, maps, slices, and strings in most Go implementations, such races can in turn lead to arbitrary memory corruption.

[nktks]

@leventov Thank you!
Indeed reading/writting accessToken happens data race.

I added test case to reproduce.
https://github.com/tmc/langchaingo/actions/runs/12176399051/job/33962066313

Then I fixed it by using sync.RWMutex.