@DanielleMaywooddoesn't the quartz docs only apply to testing? I.e. for production it uses real implementations. Re-read what you wrote, misinterpreted it the first time.

Please re-check the Go docs for the Go version we use, IIRC the implementation changed recently.

IIRC the reason for the default case is not slow receivers, it's to not queue up a periodic update if a one is already running. Allowing it should be fine though, perhaps just a bit wasteful.

By what mechanism are you proposing that removing the default case fixes the flake?

@mafredri Docs for version of go we use says the same thinghttps://pkg.go.dev/time@go1.24.2#NewTicker

I've tested locally and this fix does appear to stop the flake happening for me. As for why, I'massuming in the test scenario there is a race on theupdateTrigger channel being ready for reading.

My understanding could be entirely wrong though (although I haven't managed to get the error to occur again with the change).

IMO a better option would be to makeupdateTrigger buffered (1), because there also exists a race between the running the initial tick and the code arriving atfor loop that readsupdateTrigger.

On second thought, I overlooked one thing with dropping default so that approach is not any worse than buffering the trigger.