Summary

Reviewed at d661efb. I reproduced every claim in the description locally against this head rather than taking the body at its word; all of them hold.

Independent verification (Go 1.25.5, go/v4 resolved to the PR worktree via go list -m, confirming the local source was under test):

The tests are genuine regression gates, not tautologies. Reverting exchange_cache.go to origin/master while keeping the new test file reproduces real failures:

• The GetLimit race is exactly where you say it is — ArrayCacheByTimestamp.GetLimit writing clearUpdates against Append reading it. Polling is provably not read-only:

WARNING: DATA RACE
Write at 0x00c0002b6318 by goroutine 12:
  (*ArrayCacheByTimestamp).GetLimit()  exchange_cache.go:503
Previous read at 0x00c0002b6318 by goroutine 11:
  (*ArrayCacheByTimestamp).Append()    exchange_cache.go:435

• The Clear atomicity claim also holds. Restoring only the old two-lock Clear (leaving the new GetLimit locking in place) fails all five variants without -race, five repeats — e.g. clear exposed mismatched rows/index: 1/5, 2/1, 1/0. That is the logical interleaving bug, not a detector artifact, so the point in your description is correct.

Correctness of the locking itself. sync.Mutex is not reentrant, so the risk with this change is a self-deadlock from taking Mu in GetLimit. I checked the reachable set and found none:

• The nested caches (ArrayCacheBySymbolById, ArrayCacheByOutcomeById, ArrayCacheBySymbolBySide) delegate to ArrayCache.GetLimit exactly once, with no lock of their own.
• AppendInternal, trackAppendLocked, resetUpdateTrackersLocked and mergeRow are lock-free helpers, so the append paths still take Mu once.
• MathMin / ToString / ParseInt, now called under the lock, are pure and touch no cache state.
• No code outside exchange_cache.go locks Mu, and the generated pro/*.go callers reach GetLimit only through ToGetsLimit(...) without holding it, so no caller can enter already-locked.

Inlining Data = Data[:0] is faithful to the old BaseCache.Clear() — on master that method was only Data[:0] under the lock, so no reset was dropped in the merge.

Findings

One durability issue with the regression gate, detailed inline: CI runs go test -C go -count=1 ./v4 without -race, and the timestamp half of this fix is invisible to that command. Not merge-blocking — the fix is correct either way — but worth knowing that half of what you just fixed would not be caught if it regressed.

The scope/limitations section is accurate and I would not expand it here: GetLimit + ToArray remaining two separately locked calls is a real property of the current watch/filter interface, and fixing it belongs in a broader change, not this one.

Merge gate: 🟢
Merge probability: 85%

Follow-up on 3e04957.

Delta is two files and no behaviour change to the cache logic reviewed at d661efb:

• .github/workflows/go-app.yml adds a go test -C go -race -count=1 -run '^TestArrayCache' ./v4 step, gated on the same important_modified == 'true' condition as the existing ./v4 test step, and placed after it / before the Ws build. Anchoring the filter with ^TestArrayCache picks up the new suite (including the ByTimestamp polling case that only fails under -race), and scoping the race detector to that one regex keeps CI time bounded instead of racing the whole package. Note the gate is conditional: pushes that do not touch the watched paths will not run it, so the race check protects go/v4 changes rather than acting as an unconditional guard.
• go/v4/exchange_cache.go adds a doc comment on BaseCache.Clear telling subclasses with indexes or counters to reset storage and metadata in a single Mu critical section rather than calling this method and re-locking. That is exactly the invariant the earlier commit enforced in ArrayCacheBySymbolById/ByTimestamp, so the comment matches the shipped code.

Nothing new to flag; my earlier findings stand as addressed and this commit does not reopen any of them.

Merge gate: 🟢