@alteriom/painlessmesh 1.9.10 → 1.9.12

package/CHANGELOG.md

@@ -19,6 +19,68 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 - TBD
 
+## [1.9.12] - 2025-12-18
+
+### Fixed
+
+- **Hard Reset During Bridge Operations - AsyncClient abort() Timing Issue** - Fixed ESP32/ESP8266 heap corruption crashes during TCP connection failures and bridge operations
+  - **Root Cause**: Calling `client->abort()` synchronously before scheduling deferred AsyncClient deletion (1000ms+ later) left the client in an inconsistent state where AsyncTCP's internal cleanup tried to access the aborted client
+  - **Symptom**: Device crashes with "CORRUPT HEAP: Bad head at 0x40838cdc. Expected 0xabba1234 got 0x4200822e" and "assert failed: multi_heap_free multi_heap_poisoning.c:279" during connection cleanup
+  - **Solution**: Removed synchronous `abort()` call from `~BufferedConnection()` destructor
+    - The existing `close()` and `close(true)` calls are sufficient for connection termination
+    - According to AsyncTCP best practices, `abort()` should only be called immediately before `delete`, not before a deferred deletion
+    - Eliminates the 1000ms window where AsyncTCP tries to clean up an aborted but not-yet-deleted client
+  - **Testing**: All test suites pass (1000+ assertions), including TCP retry, connection, and mesh connectivity tests
+  - **Documentation**: Added ISSUE_ABORT_TIMING_FIX.md with detailed AsyncTCP best practices analysis
+  - **Impact**: Completes the AsyncClient lifecycle management improvements, eliminating the last known heap corruption scenario in connection cleanup
+
+## [1.9.11] - 2025-12-18
+
+### Fixed
+
+- **Hard Reset on Bridge Promotion - Unsafe addTask After stop/reinit** - Fixed ESP32/ESP8266 hard resets (Guru Meditation Error: Load access fault) immediately after bridge promotion in both isolated and election winner paths
+  - **Root Cause**: Calling `addTask()` immediately after `stop()/initAsBridge()` cycle accessed unstable internal task scheduling structures before they were fully reinitialized in the new context
+  - **Symptom**: Device crashes with "Load access fault" at MTVAL 0xbaad59d4 (freed memory marker) immediately after "🎯 PROMOTED TO BRIDGE" message when node becomes bridge through either isolated promotion or election
+  - **Solution**: Removed redundant task scheduling calls that were unsafe after stop/reinit
+    - Removed `addTask()` call in `attemptIsolatedBridgePromotion()` (line 1947)
+    - Removed `addTask()` call in `promoteToBridge()` (line 1822)
+    - Relied on existing `initBridgeStatusBroadcast()` infrastructure which safely handles announcements
+    - Used explicit `TSTRING` construction in callback invocations for string lifetime safety
+  - **Why Safe**: The removed tasks were redundant - `initBridgeStatusBroadcast()` (called by `initAsBridge()`) already sends immediate and periodic bridge status broadcasts (lines 1277-1280), and election winner path sends initial takeover announcement before stop/reinit (line 1771)
+  - **Testing**: All test suites pass (1000+ assertions), including bridge election and promotion tests
+  - **Documentation**: Added ISSUE_HARD_RESET_BRIDGE_PROMOTION_FIX.md with detailed analysis of both affected code paths
+  - **Impact**: Eliminates critical crash during bridge promotion, allows stable bridge failover operation in both isolated and competitive election scenarios
+
+- **Bridge Failover & sendToInternet Retry Connectivity** - Fixed heap corruption and request timeouts when using bridge_failover with sendToInternet() during connection instability
+  - **Root Cause**: `retryInternetRequest()` did not check mesh connectivity before attempting retry, causing routing attempts through unreachable gateways during bridge disconnection
+  - **Symptom**: Nodes experience timeouts, heap corruption ("CORRUPT HEAP: Bad head at 0x40831da0"), and system instability during bridge failover cycles when messages are queued via sendToInternet()
+  - **Solution**: Added `hasActiveMeshConnections()` check at start of `retryInternetRequest()`
+    - Retry only proceeds if mesh connections are active
+    - If disconnected, reschedules retry instead of attempting to route
+    - Prevents routing to unreachable gateways during temporary disconnection
+    - Maintains existing retry logic and exponential backoff
+  - **Testing**: Added comprehensive test coverage (catch_sendtointernet_retry_no_mesh.cpp) with 31 assertions validating disconnected retry scenarios
+  - **Documentation**: Added BRIDGE_FAILOVER_RETRY_FIX.md with detailed analysis and usage notes
+  - **Impact**: Fixes critical stability issue during bridge failover, enabling reliable sendToInternet() usage in production deployments with unstable connections
+
+- **Hard Reset During sendToInternet - Serialized AsyncClient Deletion** - Fixed ESP32/ESP8266 hard resets caused by heap corruption when multiple AsyncClient cleanup operations execute concurrently
+  - **Root Cause**: When multiple connections fail in rapid succession (e.g., during sendToInternet operations, mesh topology changes, or bridge failover), all AsyncClient deletions were scheduled with the same 1000ms delay, causing them to execute concurrently. The AsyncTCP library's internal cleanup routines cannot handle concurrent operations, leading to heap corruption.
+  - **Symptom**: Device crashes with "CORRUPT HEAP: Bad head at 0x40831da0. Expected 0xabba1234 got 0x4081faa4" even with 1000ms cleanup delay. Error occurs when multiple "Deferred cleanup of AsyncClient" messages appear nearly simultaneously.
+  - **Solution**: Implemented serialized deletion with 250ms spacing between consecutive AsyncClient deletions
+    - Added `TCP_CLIENT_DELETION_SPACING_MS` constant (250ms) to ensure deletions don't overlap
+    - Added global `lastScheduledDeletionTime` tracker to coordinate deletion timing
+    - Implemented `scheduleAsyncClientDeletion()` function that calculates proper spacing
+    - Updated `BufferedConnection` destructor and tcp.hpp error handlers to use centralized scheduler
+    - Ensures each AsyncClient deletion completes before the next one starts
+    - Handles millis() rollover and multiple concurrent deletion requests
+  - **Performance Impact**: 
+    - Single deletion: No change (1000ms)
+    - Multiple concurrent deletions: Spaced by 250ms each (total spread <1 second for typical scenarios)
+    - High-churn scenario (10 failures): Spread over ~3 seconds (still acceptable)
+  - **Testing**: All test suites pass (1000+ assertions), including new deletion spacing tests (47 assertions in tcp_retry)
+  - **Documentation**: Added ISSUE_HARD_RESET_SENDTOINTERNET_SERIALIZED_DELETION_FIX.md with detailed analysis
+  - **Impact**: Fixes critical stability issue in production deployments with high connection churn, particularly affecting sendToInternet and bridge failover scenarios
+
 ## [1.9.10] - 2025-12-15
 
 ### Fixed

package/README.md

@@ -4,7 +4,7 @@
 
 <div align="center">
 
-**Version 1.9.10** - Latest release with critical bug fixes for TCP retry and bridge failover
+**Version 1.9.12** - Latest release with AsyncClient abort() timing fix for heap corruption prevention
 
 [![CI/CD Pipeline](https://github.com/Alteriom/painlessMesh/actions/workflows/ci.yml/badge.svg)](https://github.com/Alteriom/painlessMesh/actions/workflows/ci.yml)
 [![Documentation](https://github.com/Alteriom/painlessMesh/actions/workflows/docs.yml/badge.svg)](https://github.com/Alteriom/painlessMesh/actions/workflows/docs.yml)

package/examples/bridge_failover/README.md

@@ -11,6 +11,8 @@ Regular mesh nodes do NOT have direct IP routing to the Internet. They only comm
 **To send data to the Internet from a regular mesh node, you must:**
 
 1. **Use `sendToInternet()`** - Routes data through a gateway node
+   - Call `mesh.enableSendToInternet()` on ALL nodes after mesh.init()
+   - This enables both sending (regular nodes) AND routing (bridge nodes)
 2. **Use `initAsSharedGateway()`** - Configures all nodes with direct router access (requires router credentials - see below)
 3. **Send mesh messages to the bridge** - Bridge node handles Internet communication
 

package/examples/bridge_failover/bridge_failover.ino

@@ -39,8 +39,8 @@
 //
 // To send data to the Internet from a regular node:
 //   1. Use mesh.sendToInternet() to route through a gateway
-//      - Call mesh.enableSendToInternet() on the sending node after mesh.init()
-//      - Bridge nodes (this example) do NOT need enableSendToInternet() - they route automatically
+//      - Call mesh.enableSendToInternet() AFTER mesh.init() on SENDING nodes only
+//      - Bridge nodes automatically handle routing via initAsBridge()
 //      - See examples/sendToInternet/sendToInternet.ino for complete usage
 //   2. Use initAsSharedGateway() so all nodes have router access
 //      NOTE: initAsSharedGateway() requires ROUTER credentials:
@@ -223,6 +223,13 @@ void setup() {
     // mesh.setElectionRandomDelay(10000, 30000);  // 10-30 seconds (default: 1-3 seconds)
   }
 
+  // NOTE: Bridge nodes do NOT need to call mesh.enableSendToInternet()
+  // The initAsBridge() method already sets up gateway routing via initGatewayInternetHandler()
+  // which handles incoming sendToInternet() requests from regular nodes.
+  //
+  // Only call enableSendToInternet() on nodes that will SEND requests (regular nodes).
+  // Bridge nodes only need to ROUTE requests, which is automatically configured.
+
   // Register callbacks
   mesh.onReceive(&receivedCallback);
   mesh.onNewConnection(&newConnectionCallback);

package/examples/sendToInternet/README.md

@@ -146,6 +146,23 @@ mesh.sendToInternet("https://api.callmebot.com/...", "", callback);
 3. Check HTTP status code in callback (200 = success)
 4. URL-encode special characters in the message
 
+### Understanding HTTP Status Codes
+
+The callback provides `httpStatus` to indicate the result:
+
+**SUCCESS (success = true):**
+- `200 OK` - Standard success (most common for WhatsApp API)
+- `201 Created` - Resource successfully created
+- `202 Accepted` - Request accepted for processing
+- `204 No Content` - Successful with no response body
+
+**FAILURE (success = false):**
+- `203 Non-Authoritative Information` - **Cached/proxied response, NOT actual delivery**
+- `4xx` - Client error (bad request, unauthorized, not found, etc.)
+- `5xx` - Server error (service unavailable, gateway timeout, etc.)
+
+⚠️ **Important:** HTTP 203 is treated as **FAILURE** because it indicates the response came from a cache or proxy, not from the actual WhatsApp API server. If you see `HTTP Status: 203`, the message was **NOT delivered**.
+
 ## Files
 
 - `sendToInternet.ino` - Main example sketch

package/examples/sendToInternet/sendToInternet.ino

@@ -42,9 +42,9 @@
 //    - Works as-is without any modifications needed!
 //
 // 2. SENDING NODE SETUP:
-//    - Call mesh.enableSendToInternet() AFTER mesh.init() on nodes that will SEND requests
-//    - Bridge nodes do NOT need to call enableSendToInternet() - they route automatically
-//    - This example shows how to enable it in the setup() function below
+//    - Call mesh.enableSendToInternet() AFTER mesh.init() on nodes that SEND requests.
+//    - Bridge nodes automatically handle routing via initAsBridge().
+//    - This example shows how to enable it in the setup() function below.
 //
 // For Callmebot WhatsApp API:
 // - Get your API key from https://www.callmebot.com/blog/free-api-whatsapp-messages/
@@ -184,6 +184,13 @@ void sendAlertToWhatsApp(String message) {
   
   // Use sendToInternet() to route the request through a gateway
   // The callback will be invoked when we get a response (or timeout)
+  // 
+  // SUCCESS CODES: Only specific HTTP codes indicate genuine delivery:
+  // - 200 OK: Standard success (most common for WhatsApp API)
+  // - 201 Created, 202 Accepted, 204 No Content
+  // 
+  // FAILURE: HTTP 203 (Non-Authoritative) is treated as FAILURE because
+  // it indicates a cached/proxied response, not actual delivery to WhatsApp.
   uint32_t msgId = mesh.sendToInternet(
     url,
     "",  // No payload needed for GET request - params are in URL

package/library.json

@@ -6,7 +6,7 @@
     "type": "git",
     "url": "https://github.com/Alteriom/painlessMesh"
   },
-  "version": "1.9.10",
+  "version": "1.9.12",
   "frameworks": [
     "arduino"
   ],

package/library.properties

@@ -1,5 +1,5 @@
 name=Alteriom PainlessMesh
-version=1.9.10
+version=1.9.12
 author=Coopdis,Scotty Franzyshen,Edwin van Leeuwen,Germán Martín,Maximilian Schwarz,Doanh Doanh,Alteriom
 maintainer=Alteriom
 sentence=A painless way to setup a mesh with ESP8266 and ESP32 devices with Alteriom extensions

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@alteriom/painlessmesh",
-  "version": "1.9.10",
+  "version": "1.9.12",
   "description": "painlessMesh is a user-friendly library for creating mesh networks with ESP8266 and ESP32 devices. This Alteriom fork includes additional packages for sensor data (SensorPackage), device commands (CommandPackage), and status monitoring (StatusPackage). It handles routing and network management automatically, so you can focus on your application. The library uses JSON-based messaging and syncs time across all nodes, making it ideal for coordinated behaviour like synchronized light displays or sensor networks reporting to a central node.",
   "keywords": [
     "arduino",

package/src/AlteriomPainlessMesh.h

@@ -29,10 +29,10 @@
 /**
  * @brief AlteriomPainlessMesh library version information
  */
-#define ALTERIOM_PAINLESS_MESH_VERSION "1.9.10"
+#define ALTERIOM_PAINLESS_MESH_VERSION "1.9.12"
 #define ALTERIOM_PAINLESS_MESH_VERSION_MAJOR 1
 #define ALTERIOM_PAINLESS_MESH_VERSION_MINOR 9
-#define ALTERIOM_PAINLESS_MESH_VERSION_PATCH 10
+#define ALTERIOM_PAINLESS_MESH_VERSION_PATCH 12
 
 /**
  * @brief Library description and usage information

package/src/arduino/wifi.hpp

@@ -1740,8 +1740,11 @@ class Mesh : public painlessmesh::Mesh<Connection> {
     Log(STARTUP, "=== Becoming Bridge Node ===\n");
 
     // Store previous bridge (if any)
-    auto primaryBridge = this->getPrimaryBridge();
-    uint32_t previousBridgeId = primaryBridge ? primaryBridge->nodeId : 0;
+    // SAFETY: Use getPrimaryGateway() which returns the nodeId value directly
+    // instead of getPrimaryBridge() which returns a pointer to a vector element.
+    // This avoids crashes from dangling pointers that can occur if the 
+    // knownBridges vector is modified between pointer retrieval and use.
+    uint32_t previousBridgeId = this->getPrimaryGateway();
 
     // IMPORTANT: Send takeover announcement BEFORE switching channels
     // This ensures other nodes on the current channel receive the announcement
@@ -1809,38 +1812,24 @@ class Mesh : public painlessmesh::Mesh<Connection> {
     Log(STARTUP, "✓ Bridge promotion complete on channel %d\n", _meshChannel);
 
     // Notify via callback
+    // Use explicit TSTRING construction to ensure string lifetime safety
     if (bridgeRoleChangedCallback) {
-      bridgeRoleChangedCallback(true, "Election winner - best router signal");
+      static const TSTRING reason = "Election winner - best router signal";
+      bridgeRoleChangedCallback(true, reason);
     }
 
-    // Send a follow-up announcement on the new channel
-    // This helps nodes that have already switched channels to discover the new
-    // bridge Schedule it after a delay to ensure mesh is fully initialized
-    this->addTask(3000, TASK_ONCE, [this, previousBridgeId]() {
-      Log(STARTUP,
-          "Sending follow-up takeover announcement on new channel %d\n",
-          _meshChannel);
-      JsonDocument doc2;
-      JsonObject obj2 = doc2.to<JsonObject>();
-      obj2["type"] = protocol::BRIDGE_TAKEOVER;
-      obj2["from"] = this->nodeId;
-      obj2["routing"] = 2;  // BROADCAST
-      obj2["previousBridge"] = previousBridgeId;
-      obj2["reason"] = "Election winner - best router signal";
-      obj2["routerRSSI"] = WiFi.RSSI();
-      obj2["timestamp"] = this->getNodeTime();
-      obj2["message_type"] = protocol::BRIDGE_TAKEOVER;
-
-      String msg2;
-      serializeJson(doc2, msg2);
-
-      // Send follow-up takeover using raw broadcast to preserve type
-      // BRIDGE_TAKEOVER
-      protocol::Variant variant2(msg2);
-      router::broadcast<protocol::Variant, Connection>(variant2, (*this), 0);
-
-      Log(STARTUP, "✓ Follow-up takeover announcement sent\n");
-    });
+    // Note: The initial takeover announcement was already sent earlier
+    // before the channel switch. The follow-up announcement that was previously
+    // scheduled here has been removed to avoid potential crashes from scheduling
+    // tasks immediately after stop()/reinit cycle.
+    //
+    // The bridge status broadcast system (initialized by initAsBridge via
+    // initBridgeStatusBroadcast) will continue to inform nodes about the new
+    // bridge through periodic broadcasts. Nodes that switched channels will
+    // discover the new bridge through these status broadcasts.
+    Log(STARTUP,
+        "Bridge takeover complete. Status broadcasts will announce bridge to "
+        "network.\n");
   }
 
   /**
@@ -1936,16 +1925,21 @@ class Mesh : public painlessmesh::Mesh<Connection> {
         _meshChannel);
 
     // Notify via callback
+    // Use explicit TSTRING construction to ensure string lifetime safety
     if (bridgeRoleChangedCallback) {
-      bridgeRoleChangedCallback(true, "Isolated node promoted to bridge");
+      static const TSTRING reason = "Isolated node promoted to bridge";
+      bridgeRoleChangedCallback(true, reason);
     }
 
-    // Send bridge status announcement to attract other nodes
-    this->addTask(3000, TASK_ONCE, [this]() {
-      Log(STARTUP, "Sending bridge status announcement on channel %d\n",
-          _meshChannel);
-      this->sendBridgeStatus();
-    });
+    // Note: Bridge status announcement will be sent automatically by
+    // initBridgeStatusBroadcast() which is called by initAsBridge().
+    // The immediate broadcast is scheduled in that function, so we don't
+    // need to schedule another one here. This avoids potential crashes from
+    // scheduling tasks immediately after stop()/reinit cycle.
+    // The initBridgeStatusBroadcast() also sets up periodic broadcasts.
+    Log(STARTUP,
+        "Bridge status announcement will be sent by bridge status broadcast "
+        "system\n");
 
     return true;  // Count as an attempt - we succeeded
   }
@@ -2164,10 +2158,37 @@ class Mesh : public painlessmesh::Mesh<Connection> {
           }
 
           if (httpCode > 0) {
-            // Only 2xx status codes are treated as success
+            // Only specific 2xx status codes indicate genuine success
+            // 200 OK: Standard successful response
+            // 201 Created: Resource successfully created
+            // 202 Accepted: Request accepted for processing
+            // 204 No Content: Successful with no response body
+            //
+            // Other 2xx codes like 203 (Non-Authoritative Information) often
+            // indicate cached/proxied responses that may not represent actual
+            // delivery to the destination service (e.g., WhatsApp API).
+            //
             // 3xx redirects are not automatically followed
-            success = (httpCode >= 200 && httpCode < 300);
-            Log(COMMUNICATION, "HTTP request completed: code=%d\n", httpCode);
+            success = (httpCode == 200 || httpCode == 201 || 
+                      httpCode == 202 || httpCode == 204);
+            
+            if (success) {
+              Log(COMMUNICATION, "HTTP request completed: code=%d\n", httpCode);
+            } else if (httpCode >= 200 && httpCode < 300) {
+              // Other 2xx codes - ambiguous success
+              char errorBuf[128];
+              snprintf(errorBuf, sizeof(errorBuf), 
+                      "Ambiguous response - HTTP %d may indicate cached/proxied response, not actual delivery", 
+                      httpCode);
+              error = TSTRING(errorBuf);
+              Log(ERROR, "HTTP request ambiguous: code=%d (treated as failure)\n", httpCode);
+            } else {
+              // 1xx, 3xx, 4xx, 5xx
+              char errorBuf[32];
+              snprintf(errorBuf, sizeof(errorBuf), "HTTP %d", httpCode);
+              error = TSTRING(errorBuf);
+              Log(ERROR, "HTTP request failed: code=%d\n", httpCode);
+            }
           } else {
             error = http.errorToString(httpCode);
             Log(ERROR, "HTTP request failed: %s\n", error.c_str());

package/src/painlessMesh.h

@@ -5,8 +5,8 @@
  * @file painlessMesh.h
  * @brief Main header file for Alteriom painlessMesh library
  * 
- * @version 1.9.10
- * @date 2025-12-15
+ * @version 1.9.12
+ * @date 2025-12-18
  * 
  * painlessMesh is a user-friendly library for creating mesh networks with 
  * ESP8266 and ESP32 devices. This Alteriom fork includes additional packages 

package/src/painlessmesh/connection.hpp

@@ -16,12 +16,126 @@ namespace tcp {
 
 // Delay before cleaning up failed AsyncClient after connection error or close
 // This prevents crashes when AsyncTCP library is still accessing the client internally
-// The AsyncTCP library may take a few hundred milliseconds to complete its internal cleanup
-static const uint32_t TCP_CLIENT_CLEANUP_DELAY_MS = 500; // 500ms delay before deleting AsyncClient
+// The AsyncTCP library may take several hundred milliseconds to complete its internal cleanup
+// When multiple connections are failing simultaneously (e.g., during mesh connection issues),
+// the library needs even more time to safely process multiple cleanup operations
+// Increased from 500ms to 1000ms to handle high-churn scenarios more reliably
+static const uint32_t TCP_CLIENT_CLEANUP_DELAY_MS = 1000; // 1000ms delay before deleting AsyncClient
+
+// Minimum spacing between consecutive AsyncClient deletions to prevent concurrent cleanup
+// When multiple AsyncClients are deleted in rapid succession, the AsyncTCP library's
+// internal cleanup routines can interfere with each other, causing heap corruption
+// This spacing ensures each deletion completes before the next one begins
+static const uint32_t TCP_CLIENT_DELETION_SPACING_MS = 250; // 250ms spacing between deletions
+
+// Global state to track AsyncClient deletion scheduling and execution
+// This ensures deletions are spaced out even when multiple deletion requests arrive simultaneously
+// The timestamp is updated both when a deletion is SCHEDULED and when it EXECUTES, providing
+// double protection against concurrent cleanup operations even with scheduler jitter
+// 
+// THREAD SAFETY: No synchronization needed because:
+// - ESP32/ESP8266 Arduino framework is single-threaded by design
+// - TaskScheduler executes callbacks sequentially in the main loop
+// - The scheduler never runs tasks concurrently within the same mesh instance
+// - All mesh operations (including deletion callbacks) execute in the same thread
+// - Even when multiple tasks are ready, they execute one-at-a-time via scheduler->execute()
+static uint32_t lastScheduledDeletionTime = 0; // Timestamp of last deletion scheduled/executed (milliseconds)
 
 // Shared buffer for reading/writing to the buffer
 static painlessmesh::buffer::temp_buffer_t shared_buffer;
 
+/**
+ * Schedule deletion of an AsyncClient with proper spacing to prevent concurrent cleanups
+ * 
+ * This function ensures that AsyncClient deletions are spaced out in time to prevent
+ * the AsyncTCP library's internal cleanup routines from interfering with each other.
+ * 
+ * When multiple AsyncClient objects need to be deleted (e.g., during high connection churn
+ * or sendToInternet scenarios), scheduling them all with the same delay can cause them to
+ * execute concurrently, leading to heap corruption.
+ * 
+ * This function maintains a global timestamp of when the last deletion was scheduled and
+ * calculates an appropriate delay for the new deletion to ensure adequate spacing.
+ * 
+ * @param scheduler The task scheduler to use for scheduling the deletion
+ * @param client The AsyncClient pointer to delete
+ * @param logPrefix Prefix for the log message (e.g., "~BufferedConnection" or "tcp_err")
+ */
+inline void scheduleAsyncClientDeletion(Scheduler* scheduler, AsyncClient* client, const char* logPrefix) {
+  using namespace logger;
+  
+  if (!scheduler) {
+    // Fallback: If scheduler not available, delete immediately (risky)
+    Log(CONNECTION, "%s: No scheduler available, deleting AsyncClient immediately (risky)\n", logPrefix);
+    delete client;
+    return;
+  }
+  
+  // Get current time in milliseconds
+  uint32_t currentTime = millis();
+  
+  // Calculate the earliest time this deletion should execute
+  // Base delay: TCP_CLIENT_CLEANUP_DELAY_MS (1000ms)
+  uint32_t baseDelay = TCP_CLIENT_CLEANUP_DELAY_MS;
+  
+  // Calculate when this deletion should execute relative to the last scheduled deletion
+  // If the last deletion was scheduled recently, we need to add additional spacing
+  uint32_t targetDeletionTime = currentTime + baseDelay;
+  
+  // If there's a recent deletion scheduled, ensure we space out from it
+  if (lastScheduledDeletionTime > 0) {
+    // Calculate when the next deletion slot is available
+    uint32_t nextAvailableSlot = lastScheduledDeletionTime + TCP_CLIENT_DELETION_SPACING_MS;
+    
+    // If our target deletion time is before the next available slot, push it out
+    // Handle millis() rollover: Use signed arithmetic to detect if nextAvailableSlot is "in the future"
+    // relative to targetDeletionTime. This works because:
+    // - If difference is positive and < 2^31: nextAvailableSlot is ahead, we need to wait
+    // - If difference is negative or > 2^31: nextAvailableSlot is in the past (or very far future after rollover), use targetDeletionTime
+    int32_t timeUntilSlot = (int32_t)(nextAvailableSlot - targetDeletionTime);
+    if (timeUntilSlot > 0 && timeUntilSlot < (int32_t)(1U << 30)) {
+      // nextAvailableSlot is reasonably soon in the future (< ~12 days), space from it
+      targetDeletionTime = nextAvailableSlot;
+    }
+    // else: lastScheduledDeletionTime is too old (> baseDelay+spacing), or rollover occurred
+    // In this case, just use targetDeletionTime (currentTime + baseDelay) and reset spacing
+  }
+  
+  // Calculate the actual delay from now
+  uint32_t actualDelay = targetDeletionTime - currentTime;
+  
+  // Update the last scheduled deletion time
+  // IMPORTANT: We update this when scheduling, which provides a minimum guaranteed spacing
+  // between scheduled deletions. This ensures even with scheduler jitter, deletions won't
+  // be scheduled too close together.
+  lastScheduledDeletionTime = targetDeletionTime;
+  
+  Log(CONNECTION, "%s: Scheduling AsyncClient deletion in %u ms (spaced from previous deletions)\n", 
+      logPrefix, actualDelay);
+  
+  // Schedule the deletion task
+  // Note: Task object is intentionally leaked to keep implementation simple
+  // This is acceptable because:
+  // 1. Connections are long-lived, destructor calls are infrequent
+  // 2. Task object is small (~32-64 bytes) vs preventing critical heap corruption
+  // 3. In typical deployments, memory impact is negligible (few KB over months)
+  // 4. Alternative cleanup patterns would add significant complexity
+  Task* cleanupTask = new Task(actualDelay * TASK_MILLISECOND, TASK_ONCE, [client, logPrefix]() {
+    using namespace logger;
+    Log(CONNECTION, "%s: Deferred cleanup of AsyncClient executing now\n", logPrefix);
+    
+    // Update the last deletion time when the deletion actually executes
+    // This ensures subsequent deletions are spaced from the actual execution time,
+    // not just the scheduled time, preventing concurrent cleanup operations
+    lastScheduledDeletionTime = millis();
+    
+    delete client;
+  });
+  
+  scheduler->addTask(*cleanupTask);
+  cleanupTask->enableDelayed();
+}
+
 /**
  * Class that performs buffered read and write to the tcp connection
  * (asyncclient)
@@ -51,38 +165,17 @@ class BufferedConnection
     if (!client->freeable()) {
       client->close(true);
     }
-    client->abort();
+    // Note: client->abort() removed - calling it before deferred deletion
+    // can leave the client in an inconsistent state where AsyncTCP is still
+    // trying to clean up the aborted connection. The close() and close(true)
+    // calls above are sufficient for connection termination.
+    // See: AsyncTCP best practices - abort() should only be called immediately
+    // before delete, not before a deferred deletion.
     
     // Defer deletion of the AsyncClient to prevent heap corruption
-    // Deleting immediately can cause use-after-free issues when the AsyncTCP 
-    // library is still referencing the object internally during cleanup
+    // Use the centralized deletion scheduler to ensure proper spacing between deletions
     // See ISSUE_254_HEAP_CORRUPTION_FIX.md and ASYNCCLIENT_CLEANUP_FIX.md
-    if (mScheduler) {
-      // Capture client pointer by value for safe deferred deletion
-      AsyncClient* clientToDelete = client;
-      
-      // Schedule deletion task with TCP_CLIENT_CLEANUP_DELAY_MS delay
-      // This gives AsyncTCP library time to complete its internal cleanup
-      // Note: Task object is intentionally leaked to keep implementation simple
-      // This is acceptable because:
-      // 1. Connections are long-lived, destructor calls are infrequent
-      // 2. Task object is small (~32-64 bytes) vs preventing critical heap corruption
-      // 3. In typical deployments, memory impact is negligible (few KB over months)
-      // 4. Alternative cleanup patterns would add significant complexity
-      Task* cleanupTask = new Task(TCP_CLIENT_CLEANUP_DELAY_MS * TASK_MILLISECOND, TASK_ONCE, [clientToDelete]() {
-        using namespace logger;
-        Log(CONNECTION, "~BufferedConnection: Deferred cleanup of AsyncClient\n");
-        delete clientToDelete;
-      });
-      
-      mScheduler->addTask(*cleanupTask);
-      cleanupTask->enableDelayed();
-    } else {
-      // Fallback: If scheduler not available, delete immediately
-      // This should only happen in test environments or edge cases
-      Log(CONNECTION, "~BufferedConnection: No scheduler available, deleting AsyncClient immediately (risky)\n");
-      delete client;
-    }
+    scheduleAsyncClientDeletion(mScheduler, client, "~BufferedConnection");
   }
 
   void initialize(Scheduler *scheduler) {

package/src/painlessmesh/mesh.hpp

@@ -1558,6 +1558,15 @@ class Mesh : public ntp::MeshTime, public plugin::PackageHandler<T> {
 
     PendingInternetRequest& request = it->second;
 
+    // Check mesh connectivity before attempting retry
+    // During bridge failover, connection may be temporarily lost
+    if (!hasActiveMeshConnections()) {
+      Log(logger::ERROR, "retryInternetRequest(): No active mesh connections for retry msgId=%u, rescheduling\n",
+          messageId);
+      scheduleInternetRetry(messageId);
+      return;
+    }
+
     // Find gateway (may have changed)
     BridgeInfo* gateway = getPrimaryBridge();
     if (gateway == nullptr) {

package/src/painlessmesh/tcp.hpp

@@ -135,15 +135,9 @@ void connect(AsyncClient &client, IPAddress ip, uint16_t port, M &mesh,
         }, retryDelay);
         
         // Defer deletion of the failed AsyncClient to prevent heap corruption
-        // Deleting from within the error callback can cause use-after-free issues
-        // as the AsyncTCP library may still be referencing the object
-        // Use TCP_CLIENT_CLEANUP_DELAY_MS to give AsyncTCP library time to complete
-        // its internal cleanup before we delete the object
-        // Note: client is captured by value (pointer copy) and we are the sole owner
-        mesh.addTask([client]() {
-          Log(CONNECTION, "tcp_err(): Cleaning up failed AsyncClient (retry path)\n");
-          delete client;
-        }, TCP_CLIENT_CLEANUP_DELAY_MS);
+        // Use the centralized deletion scheduler to ensure proper spacing between deletions
+        // This prevents concurrent cleanup operations in the AsyncTCP library
+        scheduleAsyncClientDeletion(mesh.mScheduler, client, "tcp_err(retry)");
         
         mesh.semaphoreGive();
         return;
@@ -156,15 +150,9 @@ void connect(AsyncClient &client, IPAddress ip, uint16_t port, M &mesh,
           TCP_CONNECT_MAX_RETRIES + 1, TCP_EXHAUSTION_RECONNECT_DELAY_MS);
       
       // Defer deletion of the failed AsyncClient to prevent heap corruption
-      // Deleting from within the error callback can cause use-after-free issues
-      // as the AsyncTCP library may still be referencing the object
-      // Use TCP_CLIENT_CLEANUP_DELAY_MS to give AsyncTCP library time to complete
-      // its internal cleanup before we delete the object
-      // Note: client is captured by value (pointer copy) and we are the sole owner
-      mesh.addTask([client]() {
-        Log(CONNECTION, "tcp_err(): Cleaning up failed AsyncClient (exhaustion path)\n");
-        delete client;
-      }, TCP_CLIENT_CLEANUP_DELAY_MS);
+      // Use the centralized deletion scheduler to ensure proper spacing between deletions
+      // This prevents concurrent cleanup operations in the AsyncTCP library
+      scheduleAsyncClientDeletion(mesh.mScheduler, client, "tcp_err(exhaustion)");
 #endif
       // Defer callback execution to avoid crashes in error handler context
       // Execute callbacks after semaphore is released and error handler completes