Bug Report - Stuck in editor-diff-fenced after architect proposal

[csala]

Issue

When working in architect mode with gemini-2.5-pro, the architect makes a proposal and when I say Yes to the edit the files question the mode switches to editor-diff-fenced mode and nothing else happens.

Then, when I exit the session I see this:

ERROR:asyncio:Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x7fcbf58a6e40>
ERROR:asyncio:Unclosed connector
connections: ['deque([(<aiohttp.client_proto.ResponseHandler object at 0x7fcbf58f1e50>, 1242859.415145305)])']
connector: <aiohttp.connector.TCPConnector object at 0x7fcbf58a6a50>

Version and model info

Version: aider-ce 0.88.33
Model: gemini-2.5-pro

[dwash96]

So for the first part, because you probably have auto-accept-architect: false, the interstitial accept of the edit lets you see the mechanic by which architect mode actually works. The "editor-diff-fenced" mode is how/when the weak model performs edits.

For the pausing, while there could be a few reasons, make sure litellm is updated to at least 1.80.5 since I think in some lower versions, there is a conflict between the logic for gemini-3 and gemini-2.5 with gemini-3's requirements with thought signatures.

It could also be a higher time-to-first-token latency than normal as well but, in my trials, I haven't gotten gemini-2.5 to completely pause even if it takes a bit to start responding. In which case, losing access to the status footer might be the effect you're observing, which might be possible depending on which shell you use. I don't observe it in a bash shell and it seems properly persistent. The errors on close sort of support this hypothesis, in that litellm was interrupted while processing a response and "nothing else" is really the request being in progress before response streaming has started

[csala]

So for the first part, because you probably have auto-accept-architect: false, the interstitial accept of the edit lets you see the mechanic by which architect mode actually works. The "editor-diff-fenced" mode is how/when the weak model performs edits.

I do have auto-accept-architect: false. But I thought this just affected the Yes/No question about whether to continue with the engineer proposal. If this is the parameter affecting the appearance of this editor-diff-fenced mode I find it rather confusing. Shouldn't there be then a separate auto-accept-engineer: true/false to control whether we stop before accepting the edits? This might actually be somewhat covered by #202, I have not fully checked it yet.

For the pausing, while there could be a few reasons, make sure litellm is updated to at least 1.80.5 since I think in some lower versions, there is a conflict between the logic for gemini-3 and gemini-2.5 with gemini-3's requirements with thought signatures.

For the record, this was happening on LiteLLM 1.80.7, so I think this can be discarded as the reason.

It could also be a higher time-to-first-token latency than normal as well but, in my trials, I haven't gotten gemini-2.5 to completely pause even if it takes a bit to start responding. In which case, losing access to the status footer might be the effect you're observing, which might be possible depending on which shell you use. I don't observe it in a bash shell and it seems properly persistent. The errors on close sort of support this hypothesis, in that litellm was interrupted while processing a response and "nothing else" is really the request being in progress before response streaming has started

I'm also on bash (GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)), so it is not a problem of a different shell.

But a latency issue sounds like a good candidate for the problem. To be honest, I waited a little bit, but I every time I killed it after a minute at most. I'll continue trying and if it happens again I'll just wait, see what happens.

If we find that latency is the culprit, we might want to look at having some feedback right away to indicate that things are happening under the hood.

[dwash96]

I do have auto-accept-architect: false. But I thought this just affected the Yes/No question about whether to continue with the engineer proposal. If this is the parameter affecting the appearance of this editor-diff-fenced mode I find it rather confusing. Shouldn't there be then a separate auto-accept-engineer: true/false to control whether we stop before accepting the edits? This might actually be somewhat covered by #202, I have not fully checked it yet.

This goes way deeper into the actually structure of the coder classes and the contention for what controls the input/output buffer than is succinctly explainable. Most literally, auto-accept-architect controls whether you are asked if the conversation context is passed off to the EditDiffFenced coder class (hence the editor-diff-fenced prefix you see on the input prompt if you say yes). If auto-accept-architect is off, you do the confirmation to edit files, which means the ArchitectCoder class yields control of the input buffer after the confirmation and the other Coder class gains control of it while generating the edits and updates the prefix. It is then switched back to the ArchitectCoder at the end of the process.

For latency, #202 does include an additional short sleep since user feedback is rendered in the bottom toolbar of the prompt input and ideally the sleep gives the system time to re-establish an input buffer after a confirmation happens.