Stream interrupted #150

New issue

Open

opened 2026-02-13 17:27:56 -06:00 by mirrors · 2 comments

mirrors commented

2026-02-13 17:27:56 -06:00

Owner

Originally created by @962209699 on GitHub (Feb 11, 2026).

2026-02-11 08:20:47.046 | DEBUG | gemini_webapi.client:_process_parts:666 - Model is in a waiting state (queueing)...
2026-02-11 08:20:47.047 | DEBUG | gemini_webapi.client:_generate:878 - Stream interrupted (completed=False, final_chunk=False, thinking=False, queueing=True). Polling again...
2026-02-11 08:20:52.261 | DEBUG | gemini_webapi.client:_process_parts:666 - Model is in a waiting state (queueing)...
2026-02-11 08:20:52.262 | DEBUG | gemini_webapi.client:_generate:878 - Stream interrupted (completed=False, final_chunk=False, thinking=False, queueing=True). Polling again...
2026-02-11 08:21:02.485 | DEBUG | gemini_webapi.client:_process_parts:666 - Model is in a waiting state (queueing)...
2026-02-11 08:21:02.487 | DEBUG | gemini_webapi.client:_generate:878 - Stream interrupted (completed=False, final_chunk=False, thinking=False, queueing=True). Polling again...
2026-02-11 08:21:17.709 | DEBUG | gemini_webapi.client:_process_parts:666 - Model is in a waiting state (queueing)...
2026-02-11 08:21:17.710 | DEBUG | gemini_webapi.client:_generate:878 - Stream interrupted (completed=False, final_chunk=False, thinking=False, queueing=True). Polling again...
2026-02-11 08:21:37.961 | DEBUG | gemini_webapi.client:_process_parts:666 - Model is in a waiting state (queueing)...
2026-02-11 08:21:37.962 | DEBUG | gemini_webapi.client:_generate:878 - Stream interrupted (completed=False, final_chunk=False, thinking=False, queueing=True). Polling again...

use v1.19.1, model=gemini-3.0-pro

Originally created by @962209699 on GitHub (Feb 11, 2026). 2026-02-11 08:20:47.046 | DEBUG | gemini_webapi.client:_process_parts:666 - Model is in a waiting state (queueing)... 2026-02-11 08:20:47.047 | DEBUG | gemini_webapi.client:_generate:878 - Stream interrupted (completed=False, final_chunk=False, thinking=False, queueing=True). Polling again... 2026-02-11 08:20:52.261 | DEBUG | gemini_webapi.client:_process_parts:666 - Model is in a waiting state (queueing)... 2026-02-11 08:20:52.262 | DEBUG | gemini_webapi.client:_generate:878 - Stream interrupted (completed=False, final_chunk=False, thinking=False, queueing=True). Polling again... 2026-02-11 08:21:02.485 | DEBUG | gemini_webapi.client:_process_parts:666 - Model is in a waiting state (queueing)... 2026-02-11 08:21:02.487 | DEBUG | gemini_webapi.client:_generate:878 - Stream interrupted (completed=False, final_chunk=False, thinking=False, queueing=True). Polling again... 2026-02-11 08:21:17.709 | DEBUG | gemini_webapi.client:_process_parts:666 - Model is in a waiting state (queueing)... 2026-02-11 08:21:17.710 | DEBUG | gemini_webapi.client:_generate:878 - Stream interrupted (completed=False, final_chunk=False, thinking=False, queueing=True). Polling again... 2026-02-11 08:21:37.961 | DEBUG | gemini_webapi.client:_process_parts:666 - Model is in a waiting state (queueing)... 2026-02-11 08:21:37.962 | DEBUG | gemini_webapi.client:_generate:878 - Stream interrupted (completed=False, final_chunk=False, thinking=False, queueing=True). Polling again... use v1.19.1, model=gemini-3.0-pro

mirrors commented

2026-02-13 17:27:56 -06:00

Author

Owner

@Roiung commented on GitHub (Feb 12, 2026):

I have identified two scenarios for this issue during my testing:

Corruption of 1psidts: The scheduled update fetched an incorrect cookie, and the values in memory and the temp file were out of sync. I only discovered this after explicitly printing the 1psidts value. You can resolve this by re-initiating the request; the init() method will then pick up the correct value stored in your temp file.
HTTP/2 Connection Reuse: The long-lived connection is being reused while the Gemini side has already closed it. Re-running init() has a chance of solving this as well.
In my current foreground script, I’ve implemented logic that only updates the value in memory if the length of 1psidts is greater than 20. In the current version 1.9.1, there doesn't seem to be any validation for values being written to memory. Additionally, I’ve added logic to immediately close the SSL connection, forcing a new SSL handshake for the next request. I am still testing these changes and cannot yet confirm if they provide a perfect fix.

@Roiung commented on GitHub (Feb 12, 2026): I have identified two scenarios for this issue during my testing: Corruption of 1psidts: The scheduled update fetched an incorrect cookie, and the values in memory and the temp file were out of sync. I only discovered this after explicitly printing the 1psidts value. You can resolve this by re-initiating the request; the init() method will then pick up the correct value stored in your temp file. HTTP/2 Connection Reuse: The long-lived connection is being reused while the Gemini side has already closed it. Re-running init() has a chance of solving this as well. In my current foreground script, I’ve implemented logic that only updates the value in memory if the length of 1psidts is greater than 20. In the current version 1.9.1, there doesn't seem to be any validation for values being written to memory. Additionally, I’ve added logic to immediately close the SSL connection, forcing a new SSL handshake for the next request. I am still testing these changes and cannot yet confirm if they provide a perfect fix.

mirrors commented

2026-02-13 17:27:56 -06:00

Author

Owner

@luuquangvu commented on GitHub (Feb 13, 2026):

The new 1.19.1 release introduces a watchdog timer to automatically reset unresponsive stream connections. Does this solution work as expected for you?

@luuquangvu commented on GitHub (Feb 13, 2026): The new 1.19.1 release introduces a watchdog timer to automatically reset unresponsive stream connections. Does this solution work as expected for you?