gateway tests: TestRestingKeyReadAgainInAnOrderedGroup has the relay hold a reading made after the key refused until the test has raised its limit (red on ubuntu CI -race at d7bdb076: "its limit raised: still rests by window till …, its windows read 3 times") — the third order 3e38bd76 didn't cover. The planning's reading, still out as the key refused, came back between the refusal and the test raising the limit; ee2588c2's re-read that follows it at once reached the relay first too, read the week still used up, and was trusted for its minute, so the planning after the raise didn't ask again and nothing lifted the rest within the test's 5 s. That is the app as designed (a key's windows are read at most once a minute; a reading made after the refusal is a true one), so the test was wrong: it assumed no reading could land between restAfter and the raise. It now models the owner raising the limit before magpie reads again: a reading that reaches the relay after the refusal waits until the limit is raised. Red before: with the first reading held 100 ms and 300 ms between the refusal and the raise (a preempted test goroutine), the old test fails 3 of 5 with CI's message ("… its windows read 3 times"); the new one passes 10 of 10, and 10 of 10 with each delay alone. Still guards ee2588c2: with the planning's reading held until after the refusal and the re-read taken out of readKeyAllowance, the new test fails 3 of 3 ("still rests by window …, read 2 times"), and passes 3 of 3 with it. go test -race -count=40 -cpu 1,2,4 -run 'TestRestingKey|TestKey|Lone|Allowance' ./internal/gateway at load average ~124, go test -race ./internal/provider, go test -race ./internal/gateway, go vet (darwin, GOOS=linux, GOOS=windows) and gofmt -l pass.

internal/gateway/key_limits_test.go

@@ -274,7 +274,21 @@ func TestRestingKeyReadAgainInAnOrderedGroup(t *testing.T) {
 	week := time.Now().Add(72 * time.Hour).Truncate(time.Second).Format(time.RFC3339)
 	var mu sync.Mutex
 	limit, reads, raised := 800, 0, 0
+	// the owner raises the limit after the key refused, before magpie
+	// reads its windows again: a reading that reaches the relay after the
+	// refusal waits for it. Else the reading ee2588c2 asks again at once,
+	// once one still out as the key refused is back, could reach the
+	// relay first (a loaded CI runner), see the week still used up and be
+	// trusted for its minute, past this test's wait (d7bdb076's CI)
+	var refused bool
+	raise := make(chan struct{})
 	relay := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+		mu.Lock()
+		held := refused
+		mu.Unlock()
+		if held {
+			<-raise
+		}
 		mu.Lock()
 		l := limit
 		reads++
@@ -322,6 +336,16 @@ func TestRestingKeyReadAgainInAnOrderedGroup(t *testing.T) {
 	a := cs[0]
 	t.Cleanup(func() { clearRest(a.restKey()) })
 	quota := []byte(`{"error":{"message":"api key 7天限额已用完","type":"rate_limit_exceeded"}}`)
+	mu.Lock()
+	refused = true
+	mu.Unlock()
+	defer func() {
+		select {
+		case <-raise:
+		default:
+			close(raise) // failed before the limit was raised
+		}
+	}()
 	if r := s.restAfter(a, 429, http.Header{}, quota); r.Why != failQuota || r.By != "window" {
 		t.Fatalf("out of its week: rests by %s (%s)", r.By, r.Why)
 	}
@@ -330,6 +354,7 @@ func TestRestingKeyReadAgainInAnOrderedGroup(t *testing.T) {
 	mu.Lock()
 	limit = 1000
 	mu.Unlock()
+	close(raise)
 	// a reading out as the key refused is followed by another at once,
 	// which may have seen the limit raised and brought it back already
 	at, r := first()