Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
106639: stmtdiagnostics: de-flake TestDiagnosticsRequest for good r=yuzefovich a=yuzefovich **stmtdiagnostics: fix possible race when polling is disabled** This commit fixes a possible race on `timeutil.Timer.C` that can happen when polling interval is disabled. In particular, the race would occur because disabling the polling `Stop`s the timer which puts it back into the pool which disallows further access to the `Timer` object. However, we already stored the reference to `Timer.C`, so we'd read from the channel which could be concurrently overwritten by another goroutine (that happened to pick up this timer object from the pool). To solve this race we now store the channel separately and explicitly nil it out after having stopped the timer (which makes it block forever, until the polling interval is changed). Additionally, this commit adds non-negative validation to the cluster setting since there is really no point in allowing negative durations for the polling interval. Release note: None **stmtdiagnostics: de-flake TestDiagnosticsRequest for good** This commit - hopefully - de-flakes TestDiagnosticsRequest for good. In particular, we recently merged a change to remove the request from the local registry _before_ inserting the bundle. This introduced a possible race between the bundle being inserted (which also marks the request as "completed") and the polling mechanism of the registry to populate itself: if the polling happens to happen before the request is marked as "completed", then the request will be reinserted into the registry which then fails the test (because it'll observe later than the request is complete, yet the request is still in the registry). To prevent flakes of this kind the test now disables the polling mechanism of the registry altogether - I don't think it is necessary since the test is manually inserting requests directly into the registry (in addition to writing them into the system table). I believe this polling mechanism was the reason for why we had to use SucceedsSoon in one of the test cases, so disabling the mechanism allows us to address an old TODO. (I believe what was happening rarely was that the request was canceled by the test case - which removes it from the registry, but then before the query is executed, the polling takes place, so the request is reinserted into the registry.) Fixes: cockroachdb#106582. Release note: None Co-authored-by: Yahor Yuzefovich <[email protected]>
- Loading branch information