-
Notifications
You must be signed in to change notification settings - Fork 1.3k
It's always stuck. #2352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Are you using a custom prompt or memory bank system? Your response data says "[TASK RESUMPTION] This task was interrupted 11 minutes ago. It may or may not be complete, so please reassess the task context. Be aware that the project state may have changed since then. The current working directory is now 'd:/软件编写/Anki-TTS-Edge'. If the task has not been completed, retry the last step before interruption and proceed with completing the task." which seems that the prompting is causing problems. |
Just chiming in, same issue here. Fairly consistent on large files. Happy to help debug if you can give me some pointers. |
+1 for the same thing happening here exclusively with Gemini 2.5 ( Conditions under which this happens:
The behavior for me is that it will:
|
Can you pleaes share a little more about your setup? Are you running any sort of memory bank? Is this still happening with the updates we have made since you posted this? We have been focusing heavily on improving the diff editing as we want to make sure this works for you! |
@hannesrudolph Hi,I've found that this issue occurs regardless of whether custom or default prompts are used. The fundamental reason is API interruption, which happens easily, especially with long contexts. Sometimes, the API might only return partial information, stopping mid-sentence without finishing, which also leads to the process getting stuck. At other times, factors like network instability might also cause this problem. Essentially, the core issue is that when the API response is returned to Roo, Roo cannot recognize that it has been interrupted. I have still been encountering this frequently recently. Would it be possible to add settings for users to specify the time interval and number of attempts for automatic retries upon API response interruption? (An API response interruption typically means that after inputting text, it stops generating further output, or there is simply no response at all). This should provide a good solution to this problem. |
@mrubens thoughts? |
For me the context size was relatively small (14k tokens) against Gemini 2.5 Pro Preview and it just gets stuck and spins endlessly. The Roo Output window doesn't show anything meaningful and it never times out either, just spins at "API Request...". Anecdotal but seems to occur more when transitioning from Architect to Code. In some situations, |
What is happening at the time it spins? What is Roo trying to do at that time? |
Based on my own experience, Roo is usually in the middle of modifying code at this time, but if the API is interrupted, it will keep waiting for the API's information. At this point, only the user actively canceling can stop its waiting. |
cant repro |
App Version
Version: 3.11.8
API Provider
OpenRouter
Model Used
google/gemini-2.5-pro-exp-03-25:free
Actual vs. Expected Behavior
When using Gemini 2.5 Pro to edit code exceeding 400 lines, it easily gets stuck and shows no action.
When reading long code (over 300 lines) via API, it often gets stuck, remaining stuck in the API request.
Detailed Steps to Reproduce
1.When using Gemini 2.5 Pro to edit code exceeding 400 lines, it easily gets stuck and shows no action.
2.When reading long code (over 300 lines) via API, it often gets stuck, remaining stuck in the API request.
Relevant API Request Output
Additional Context
The text was updated successfully, but these errors were encountered: