@alteriom/painlessmesh 1.9.9 → 1.9.11

package/CHANGELOG.md

@@ -19,6 +19,86 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 - TBD
 
+## [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
+
+- **TCP Connection Retry Immediate Execution** - Fixed mesh connection failures where TCP retries executed immediately instead of with exponential backoff delays
+  - **Root Cause**: `PackageHandler::addTask()` was calling `task->enable()` instead of `task->enableDelayed()` for one-shot delayed tasks, causing immediate execution
+  - **Symptom**: Nodes unable to establish mesh connection - TCP error -14 (ERR_CONN) with all retry attempts happening immediately rather than with 1s, 2s, 4s, 8s, 8s delays
+  - **Solution**: Modified `PackageHandler::addTask()` to use `enableDelayed()` for `TASK_ONCE` tasks with intervals > 0
+    - Retry tasks now properly wait for their scheduled delays before executing
+    - Exponential backoff mechanism now works as designed (total ~23s before WiFi reconnection)
+    - Reduces network congestion from multiple simultaneously retrying nodes
+  - **Impact**: Enables successful mesh connection establishment with proper retry timing
+  - **Files Modified**: 
+    - `src/painlessmesh/plugin.hpp` (lines 231, 239, 245-251)
+    - `docs/troubleshooting/common-issues.md` (lines 206-212)
+    - `test/catch/catch_delayed_task_execution.cpp` (new test file)
+    - `ISSUE_TCP_RETRY_FIX.md` (new documentation)
+
+- **Hard Reset on Bridge Failover Election Winner** - Fixed ESP32 hard reset (Guru Meditation Error: Load access fault) when node becomes bridge after election
+  - **Root Cause**: The `bridgeRoleChangedCallback` signature used pass-by-value for the String parameter (`TSTRING reason`), causing temporary String object creation from const char* literals. On memory-constrained ESP32/ESP8266, this could trigger heap allocation failures and memory access faults
+  - **Symptom**: Device crashes with "Guru Meditation Error: Core 0 panic'ed (Load access fault)" immediately after logging "🎯 PROMOTED TO BRIDGE: Election winner - best router signal"
+  - **Solution**: Changed callback signature to use const reference (`const TSTRING& reason`) instead of pass-by-value
+    - Eliminates unnecessary String object copying and temporary creation
+    - Reduces memory pressure during callback invocation
+    - String literals are now directly bound to const references without heap allocation
+  - **Impact**: Eliminates hard resets during bridge promotion, allows stable failover operation
+  - **Breaking Change**: Users must update their callback function signatures from `void callback(bool, String)` to `void callback(bool, const String&)`
+  - **Files Modified**: 
+    - `src/arduino/wifi.hpp` (lines 970, 2326)
+    - `examples/bridge_failover/bridge_failover.ino` (line 147)
+    - `README.md` (line 171)
+    - `USER_GUIDE.md` (line 731)
+
 ## [1.9.9] - 2025-12-14
 
 ### Fixed

package/README.md

@@ -4,7 +4,7 @@
 
 <div align="center">
 
-**Version 1.9.9** - Latest release with AsyncClient cleanup fixes for improved stability
+**Version 1.9.11** - Latest release with critical stability fixes for bridge promotion and AsyncClient cleanup
 
 [![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)
@@ -168,7 +168,7 @@ mesh.setRouterCredentials(ROUTER_SSID, ROUTER_PASSWORD);
 mesh.enableBridgeFailover(true);
 mesh.onBridgeRoleChanged(&bridgeRoleCallback);
 
-void bridgeRoleCallback(bool isBridge, String reason) {
+void bridgeRoleCallback(bool isBridge, const String& reason) {
   if (isBridge) {
     Serial.printf("🎯 Promoted to bridge: %s\n", reason.c_str());
   }

package/docs/troubleshooting/common-issues.md

@@ -205,11 +205,12 @@ For Arduino IDE, install manually from: https://github.com/ESP32Async/AsyncTCP
 
 #### 2. Built-in Retry Mechanism
 painlessMesh now includes automatic TCP connection retry with the following behavior:
-- Up to 3 retry attempts with 500ms delay between each
-- 100ms stabilization delay after IP acquisition before first connection attempt
-- Full WiFi reconnection only triggered after all retries are exhausted
+- Up to 6 total connection attempts (initial + 5 retries)
+- Exponential backoff delays between retries: 1s, 2s, 4s, 8s, 8s (total ~23s)
+- 500ms stabilization delay after IP acquisition before first connection attempt
+- Full WiFi reconnection with 10s delay only triggered after all retries are exhausted
 
-This helps handle transient timing issues automatically.
+This exponential backoff helps handle transient timing issues automatically while reducing network congestion from multiple retrying nodes.
 
 #### 3. Check Node Resource Usage
 Monitor memory and ensure nodes aren't overloaded:

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:
@@ -144,7 +144,7 @@ void bridgeStatusCallback(uint32_t bridgeNodeId, bool hasInternet) {
   }
 }
 
-void bridgeRoleCallback(bool isBridge, String reason) {
+void bridgeRoleCallback(bool isBridge, const String& reason) {
   if (isBridge) {
     Serial.printf("🎯 PROMOTED TO BRIDGE: %s\n", reason.c_str());
     Serial.println("This node is now the primary bridge!");
@@ -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/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/

package/library.json

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

package/library.properties

@@ -1,5 +1,5 @@
 name=Alteriom PainlessMesh
-version=1.9.9
+version=1.9.11
 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.9",
+  "version": "1.9.11",
   "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",
@@ -40,7 +40,7 @@
   },
   "devDependencies": {
     "@alteriom/mqtt-schema": "^0.8.0",
-    "@eslint/js": "^9.39.1",
+    "@eslint/js": "^9.39.2",
     "ajv": "^8.17.1",
     "ajv-formats": "^3.0.1",
     "prettier": "^3.7.4"

package/src/AlteriomPainlessMesh.h

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

package/src/arduino/wifi.hpp

@@ -967,7 +967,7 @@ class Mesh : public painlessmesh::Mesh<Connection> {
    * @param callback Function to call when role changes
    */
   void onBridgeRoleChanged(
-      std::function<void(bool isBridge, TSTRING reason)> callback) {
+      std::function<void(bool isBridge, const TSTRING& reason)> callback) {
     bridgeRoleChangedCallback = callback;
   }
 
@@ -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
   }
@@ -2323,7 +2317,7 @@ class Mesh : public painlessmesh::Mesh<Connection> {
   ElectionState electionState = ELECTION_IDLE;
   uint32_t electionDeadline = 0;
   std::vector<BridgeCandidate> electionCandidates;
-  std::function<void(bool isBridge, TSTRING reason)> bridgeRoleChangedCallback;
+  std::function<void(bool isBridge, const TSTRING& reason)> bridgeRoleChangedCallback;
 
   // Isolated bridge retry state and configuration
   uint8_t _isolatedBridgeRetryAttempts = 0;

package/src/painlessMesh.h

@@ -5,8 +5,8 @@
  * @file painlessMesh.h
  * @brief Main header file for Alteriom painlessMesh library
  * 
- * @version 1.9.9
- * @date 2025-12-14
+ * @version 1.9.11
+ * @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,110 @@ 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
+// This ensures deletions are spaced out even when multiple deletion requests arrive simultaneously
+// Note: Thread safety is not required - ESP32/ESP8266 mesh runs single-threaded in Arduino framework
+// All mesh operations occur in the main loop or scheduler callbacks, never concurrently
+static uint32_t lastScheduledDeletionTime = 0; // Timestamp when last deletion was scheduled (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
+  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);
+    delete client;
+  });
+  
+  scheduler->addTask(*cleanupTask);
+  cleanupTask->enableDelayed();
+}
+
 /**
  * Class that performs buffered read and write to the tcp connection
  * (asyncclient)
@@ -54,35 +152,9 @@ class BufferedConnection
     client->abort();
     
     // 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/plugin.hpp

@@ -228,7 +228,13 @@ class PackageHandler : public layout::Layout<T> {
     for (auto&& task : taskList) {
       if (task.use_count() == 1 && !task->isEnabled()) {
         task->set(aInterval, aIterations, aCallback, NULL, NULL);
-        task->enable();
+        // Use enableDelayed() for delayed one-shot tasks to prevent immediate execution
+        // This ensures tasks with intervals execute after the delay, not immediately
+        if (aInterval > 0 && aIterations == TASK_ONCE) {
+          task->enableDelayed();
+        } else {
+          task->enable();
+        }
         return task;
       }
     }
@@ -236,7 +242,13 @@ class PackageHandler : public layout::Layout<T> {
     std::shared_ptr<Task> task =
         std::make_shared<Task>(aInterval, aIterations, aCallback);
     scheduler.addTask((*task));
-    task->enable();
+    // Use enableDelayed() for delayed one-shot tasks to prevent immediate execution
+    // This ensures tasks with intervals execute after the delay, not immediately
+    if (aInterval > 0 && aIterations == TASK_ONCE) {
+      task->enableDelayed();
+    } else {
+      task->enable();
+    }
     taskList.push_front(task);
     return task;
   }

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