Relay Domain-Reload Blocking

Steps to reproduce:

it's not easy to reproduce this problem. You have to retry many times. You may might once after re-trying 5 times.

1. Use prompt "create a helix jump game" in AIA. Do not enter plan mode. Just let subagents(developer) to implement the code. 

Actual results: 

The agent worked normally for several minutes, then the chat froze on the "reasoning" spinner and never produced another word. FE log is attached. 

Expected results: 

Reproducible with versions: 

Not reproducible with versions: 

Can’t test with versions: 

Tested on (OS): 

Notes:

Some analyse by CC: 

 

What happened

A user asked AI Assistant in the Unity Editor to "create a helix jump game". The agent worked normally for several minutes, then the chat froze on the "reasoning" spinner and never produced another word.

The relay entered domain-reload blocking mode at 20:51:57 UTC and never left it. From that moment every cloud-to-editor message was silently discarded, so the Editor received nothing further and the UI had nothing to advance to. The last thing the front end ever received was the tool call for a CodeEdit on GameManager.cs, four seconds earlier.

Environment: conversation b7663af1-a299-4c13-a85b-8d476d889776, conversation_kind=unity_editor, Editor 6000.5.7f1, package 2.18.0-pre.1, relay 1.0.12-build.99.

Timeline

All times UTC, from the relay log.

After the 20:51:57 block there is no connection.lost, no reconnect and no "communication is unblocked" through the end of the log. The editor's socket stayed OPEN the whole time.

Each dropped call costs a full 600s before the backend surfaces a timeout, feeds it back to the model, and the model retries into the same void — so the session grinds in ten-minute cycles with the spinner never moving.

Root cause

The relay's block state has no timeout. It can only be lifted by a client reconnect, and the safety net that would otherwise rescue it is cancelled at the moment of blocking.

• message-sender.ts:96 — unblock() is documented as "Called when a new client connects", and that is the only path.
• relay-editor.ts:725 — enterBlockingMode() calls cancelAutoRecovery() and then blocks, on the assumption stated in its own comment: "The reconnect that follows re-arms the net."
• relay-editor.ts:246 — the 60s net (AUTO_RECOVERY_GRACE_MS) is armed only inside handleClientConnection.
• RelayService.cs:344-345 — the block is signalled before the reload, on beforeAssemblyReload / OnRequestReload.

The reload never completed, so the socket never dropped, so there was no reconnect — which means no unblock(), and a net that had been cancelled and was never re-armed. Permanently wedged.

Two things make it invisible. The relay never pings the editor (relay-editor.ts:354 only answers RELAY_PING), so a connected-but-wedged editor cannot be detected. And the only evidence left behind is Relay->Editor message was not sent at DEBUG level, which does not surface in production.

What stalled the reload

The Unity log pins the trigger to the same second (13:51:57 local = 20:51:57 UTC), from the very CodeEdit that was in flight:

 

{{Assets/Scripts/Gameplay/GameManager.cs(4,17): error CS0234: namespace 'UI' does not exist in 'HelixJump'
Assets/Scripts/Gameplay/GameManager.cs(25,34): error CS0246: 'UIManager' could not be found
Warning: Script updater for .../Assembly-CSharp.dll failed to produce updates.txt}}

Assembly-CSharp failed to build. Note that CodeEditTool.cs:277 only calls ForceDomainReload() when compilationResult.Success — so this block did not come from the tool's explicit reload request. It came from the beforeAssemblyReload hook, for a reload Unity then did not carry through with a live domain swap.

That last part is arguably Unity Editor behaviour rather than muse-editor's. What makes this a bug rather than bad luck is that the relay treats an unverified future event, the reconnect, as guaranteed, with no fallback if it never arrives.