Streaming requests aborted prematurely when HTTP timeout is set

[ainilili]

Setting any HTTP timeout makes the client cancel streaming calls as soon as the timer expires, even though the stream is still healthy.

https://github.com/googleapis/go-genai/blob/main/api_client.go#L58-L65

[ainilili]

I’ve created a pull request to fix this issue. #648

[ppipada]

@Sivasankaran25 @ainilili,

I am also hitting this on my side.

Root cause looks like this:

• sendStreamRequest() creates a derived timeout context from HTTPOptions.Timeout
• but it does defer cancel() inside sendStreamRequest()
• that function returns before the stream body is actually consumed
• the real body read happens later in iterateResponseStream()

So in the streaming case, if HTTPOptions.Timeout is set, and the parent ctx has no deadline, or has a later deadline than HTTPOptions.Timeout then the SDK creates a child timeout context and cancels it as soon as sendStreamRequest() returns. The iterator then tries to read from a stream whose request context has already been canceled. If the parent ctx already has an earlier or equal deadline, then this path wont trigger, since isTimeoutBeforeDeadline(...) should skip creating that extra timeout context.

Workaround: for streaming only, we can apply the timeout on the consumer side ctx and clear HTTPOptions.Timeout before calling GenerateContentStream.

Suggested fix here:

• do not defer cancel() in sendStreamRequest() on success
• keep that cancel func alive with the stream state
• call it only: if stream setup fails before returning, or when the iterator is done and the response body is being closed

That should keep the timeout context alive for the actual stream lifetime.