For quite a long time now, sometime the agent mode was introduced, I’ve been having a bug when I send a message to the AI, it will remain stuck on the “…”
The only solution is to edit my message and press enter to try send it again.
Looking at my usage in Cursor dashboard, I see when it gets stuck it never reaches Cursor’s server, as the usage for the message never gets recorded.
I can immediately tell if a message is going to be stuck by:
Send message
Go to usage dashboard
Refresh page, if it shows an entry for the message I just sent, it won’t be stuck. If it doesn’t, it will be stuck.
I’d say roughly ~20% of my messages get stuck like this and I need to resend them.
As a workaround, I wish there could be an indictor that Cursor actually received my message. I’ve been checking the usage dashboard since models like o3-mini take extra time during “…” so otherwise I can’t tell if it’s stuck or just thinking.
The chat is brand new, the one file attached is 229 lines of code – so I would rule out any issue of large context.
I don’t think there’s any indicators in the console logs whether it’s going to be stuck or not, but I’ll keep an eye out – I checked in the past and didn’t find any pattern.
After several minutes (~10 mins), it finally did error out. Logs:
I came back an hour later. I copied the message that was stuck (since I actually want to implement it), and pasted it in a new chat.
Coincidently it got stuck again and not recorded in usage history. ID: fca26e84-9044-4d63-9dd2-0b6889e72593
After once again starting a new chat and pasting it; doesn’t get stuck and AI responded. Here’s the successful message that had the same exact message and file attached: 43f1fee7-22da-461a-bf95-682095e4826c
Though I don’t think there’s any pattern or specific messages that get stuck, seems random.
Hey, both of those request IDs look different behind the scenes, but I’ll pass to the team to take a look at. Thanks for trying to identify a pattern here!
I’m still having this issue in 0.46.3. However, fortunately it now errors after a few seconds, as opposed to the old version where it would be forever “loading”.
Here you can see it happening. I resend the message and it goes through.
When it errors out like this, only error in console is generic aborted connection error:
workbench.desktop.main.js:591 ConnectError: [aborted] read ECONNRESET
at xhs.$streamAiConnect (workbench.desktop.main.js:2318:110715)
at async workbench.desktop.main.js:459:172425
at async w_t.toolWrappedStream (workbench.desktop.main.js:965:4404)
at async zC (workbench.desktop.main.js:591:4354)
at async vc.handleStreamComposer (workbench.desktop.main.js:922:2033)
at async TLt.streamResponse (workbench.desktop.main.js:591:13950)
at async bVt.<anonymous> (workbench.desktop.main.js:2976:872)
at async pVt.<anonymous> (workbench.desktop.main.js:2935:2413)
at async KR.processCodeBlocks (workbench.desktop.main.js:948:1926)
at async workbench.desktop.main.js:1918:21472
streamResponse @ workbench.desktop.main.js:591
workbench.desktop.main.js:1918 [composer] Error in AI response: ConnectError: [aborted] read ECONNRESET
at xhs.$streamAiConnect (workbench.desktop.main.js:2318:110715)
at async workbench.desktop.main.js:459:172425
at async w_t.toolWrappedStream (workbench.desktop.main.js:965:4404)
at async zC (workbench.desktop.main.js:591:4354)
at async vc.handleStreamComposer (workbench.desktop.main.js:922:2033)
at async TLt.streamResponse (workbench.desktop.main.js:591:13950)
at async bVt.<anonymous> (workbench.desktop.main.js:2976:872)
at async pVt.<anonymous> (workbench.desktop.main.js:2935:2413)
at async KR.processCodeBlocks (workbench.desktop.main.js:948:1926)
at async workbench.desktop.main.js:1918:21472
(anonymous) @ workbench.desktop.main.js:1918
workbench.desktop.main.js:1918 [composer] Failed to get complete AI response
