From d0dac3246c5cef248b51e225d0537d9626bb87f9 Mon Sep 17 00:00:00 2001
From: liamcottle <liam@liamcottle.com>
Date: Tue, 19 Nov 2024 22:45:22 +1300
Subject: [PATCH] just set a different abort controller instead of duplicating
 internal disconnect logic

---
 src/js/Connection.js | 25 +++++++++----------------
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/src/js/Connection.js b/src/js/Connection.js
index 9fd0758..3fb8224 100644
--- a/src/js/Connection.js
+++ b/src/js/Connection.js
@@ -113,28 +113,21 @@ class Connection {
             return;
         }
 
-        // disconnect
+        // fix issue with http connection abort controller
         if(GlobalState.connection instanceof HttpConnection){
-
-            // fixme: this should probably be fixed in @meshtastic/js directly
             // calling disconnect() on an HttpConnection during the initial config fetching locks up the web page
             // this is caused by an infinite loop of errors with the below message:
             // ERROR	[iMeshDevice:HttpConnection]	ReadFromRadio ❌ signal is aborted without reason
-            // to fix this, we are calling the same internal methods that disconnect() does
-            // however, we are skipping the call to abortController.abort(), this reliably fixes the issue
-            // and no longer locks up the page, however we still get packet callbacks until the config phase finishes
-            // I don't really care if a few more packets come in after disconnecting
-            GlobalState.connection.updateDeviceStatus(Types.DeviceStatusEnum.DeviceDisconnected);
-            if(GlobalState.connection.readLoop){
-                clearInterval(GlobalState.connection.readLoop);
-                GlobalState.connection.complete();
-            }
-
-        } else {
-            // disconnect normally
-            GlobalState.connection.disconnect();
+            // to fix this, we are just overwriting the internal abortController with a new instance that won't abort the pending internal http requests
+            // this reliably fixes the issue and no longer locks up the page, however we still get packet callbacks until the config phase finishes
+            // I don't really care if a few more packets come in after disconnecting, so this will do for now
+            // fixme: this should probably be fixed in @meshtastic/js directly, probably by breaking out of the while loop if an abort error is received
+            GlobalState.connection.abortController = new AbortController();
         }
 
+        // disconnect
+        GlobalState.connection.disconnect();
+
         // update ui
         GlobalState.isConnected = false;