The realtime WYSIWYG editor remains stuck on "Connecting" after reconnecting when it was the only one editing

Kenan Alci thanks a lot for the detailed report. Your scenario (sole editor, WebSocket closed abruptly, the reconnect fails with ENOENT because the old channels were removed, then an endless series of NO_SUCH_CHANNEL errors and no save) is the one described in this issue, and it is fixed on master by three commits:

• The editor no longer waits forever for the auto-saver to settle when the connection is lost. The NO_SUCH_CHANNEL errors you saw were the pending auto-saver state being resent again and again to the old (removed) channel, while the editor was waiting for it before joining the new realtime session (wysiwygEditor.js:905 is only the console wrapper used for debugging). Now the editor leaves the old realtime session, joins a new one with the current content of the editor, and you can continue editing.
• The user data synchronization (the other users' carets) no longer tries to rejoin its removed channel, which was the cause of the ENOENT error.
• If the editor fails to join or rejoin the realtime session (e.g. because the user session has expired), it leaves the realtime session and lets the user continue editing alone, with an error notification, instead of silently dropping the changes. This covers the "at least stop and tell the user" part of your expectation.
• The changes made before the connection loss that were not saved yet remain marked as unsaved after reconnecting, so they are auto-saved (previously the toolbar showed "Saved" and they were saved only after the next change).

The realtime wiki editor got the same fixes, and the functional tests now simulate a connection loss while editing alone. The fix will be available in 18.9.0. Until then, disabling the xwiki-realtime CKEditor plugin, as you did, is the right workaround.