fix(coderd/x/chatd): stabilize flaky request-count assertion in round-trip test (#23843)

The flaky test assumed the second streamed OpenAI request had already
been captured when the chat status event arrived. In practice, the
capture server can record that second request slightly later, which
intermittently left `streamRequestCount` at `1`.

This change waits for the second captured request before asserting on
the follow-up payload and relaxes the count check to a sanity check. The
test still verifies the `store=false` round-trip behavior without
depending on that timing race.

Fixes coder/internal#1433
This commit is contained in:
Michael Suchacz
2026-03-31 13:09:11 +02:00
committed by GitHub
parent 3190406de3
commit af678606fc
+11 -2
View File
@@ -853,8 +853,17 @@ func runOpenAIReasoningWithWebSearchRoundTripTest(t *testing.T, storeMode openAI
"follow-up should have added more messages")
require.NotNil(t, findLastAssistantWithText(t, chatMsgs2.Messages),
"expected an assistant message with text after the follow-up")
require.Equal(t, int32(2), streamRequestCount.Load(),
"expected exactly two streamed OpenAI responses")
// waitForChatDone returns on the chat status event, which can arrive
// before the capture server records the second streamed request.
captureCtx, cancel := context.WithTimeout(ctx, testutil.WaitShort)
defer cancel()
require.True(t, testutil.Eventually(captureCtx, t, func(context.Context) bool {
mu.Lock()
defer mu.Unlock()
return secondReq != nil
}, testutil.IntervalFast), "expected second streaming request to be captured")
require.GreaterOrEqual(t, streamRequestCount.Load(), int32(2),
"expected at least two streamed OpenAI responses")
mu.Lock()
defer mu.Unlock()