@alteriom/painlessmesh 1.9.11 → 1.9.12

package/CHANGELOG.md

@@ -19,6 +19,21 @@ 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

package/README.md

@@ -4,7 +4,7 @@
 
 <div align="center">
 
-**Version 1.9.11** - Latest release with critical stability fixes for bridge promotion and AsyncClient cleanup
+**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/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

@@ -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.11",
+  "version": "1.9.12",
   "frameworks": [
     "arduino"
   ],

package/library.properties

@@ -1,5 +1,5 @@
 name=Alteriom PainlessMesh
-version=1.9.11
+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.11",
+  "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.11"
+#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 11
+#define ALTERIOM_PAINLESS_MESH_VERSION_PATCH 12
 
 /**
  * @brief Library description and usage information

package/src/arduino/wifi.hpp

@@ -2158,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,7 +5,7 @@
  * @file painlessMesh.h
  * @brief Main header file for Alteriom painlessMesh library
  * 
- * @version 1.9.11
+ * @version 1.9.12
  * @date 2025-12-18
  * 
  * painlessMesh is a user-friendly library for creating mesh networks with 

package/src/painlessmesh/connection.hpp

@@ -28,11 +28,18 @@ static const uint32_t TCP_CLIENT_CLEANUP_DELAY_MS = 1000; // 1000ms delay before
 // 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
+// Global state to track AsyncClient deletion scheduling and execution
 // 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)
+// 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;
@@ -98,6 +105,9 @@ inline void scheduleAsyncClientDeletion(Scheduler* scheduler, AsyncClient* clien
   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", 
@@ -113,6 +123,12 @@ inline void scheduleAsyncClientDeletion(Scheduler* scheduler, AsyncClient* clien
   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;
   });
   
@@ -149,7 +165,12 @@ 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
     // Use the centralized deletion scheduler to ensure proper spacing between deletions