@alteriom/painlessmesh 2.0.2 → 2.0.3

package/CHANGELOG.md

@@ -7,6 +7,96 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [2.0.3] - 2026-09-11
+
+`sendToInternet()` fixes from one user's WhatsApp integration (#450, #452,
+#453), and one the hardware rig found while validating them. **Upgrade if a
+node of yours is a bridge or relays to the Internet**: on 2.0.2 a bridge's own
+sends were refused for 30 s after boot, a service that answered a refusal with
+HTTP 201 was reported as delivered, a destination that does not resolve
+stalled an ESP32 gateway on every attempt, and a bridge that rebooted as a
+regular node swallowed every request its peers still sent it. Every fix was
+reproduced first -- against the new HTTP test point, which CI now runs, or
+over real TCP on the desktop -- and is covered by a row on the hardware farm.
+
+### Fixed
+
+- **A bridge's own `sendToInternet()` was refused for the first 30 s after
+  `initAsBridge()`** (#450). The Internet health check is armed one line after
+  `stationManual()` re-issues `WiFi.begin()`, so its first probe ran while the
+  station was still associating and failed, and the next was a full interval
+  away. Every send from the bridge in that window fell through to the mesh
+  path and was refused with "No active mesh connections" -- #445 again, with
+  a 30 s hole instead of forever. `sendToInternet()` and the retry path now
+  spend one on-demand probe per interval when the flag says no, and the
+  station's got-IP event re-probes at once on a bridge or shared gateway.
+- **A gateway reported a refusal as delivered, and every failure as a bare
+  number** (#450, #452). The gateway decided on the HTTP status alone and
+  discarded the response body. CallMeBot's WhatsApp API answers "Too many
+  requests" with HTTP 201 and HTTP 203, the same page under both, so a refused
+  message sent through a gateway on 2.0.2 could be reported as delivered; and
+  it answers HTTP 208 to messages it never delivers, which 2.0.2 reported as
+  "Ambiguous response" with nothing to say why. The gateway now reads the
+  start of the body (bounded to 512 bytes and 250 ms). Only 200, 201, 202 and
+  204 count as delivered, and not when the body says the service refused the
+  request; every other 2xx is a failure. Every failure reaches the origin
+  node's callback with a one-line, tag-free excerpt of the body -- for example
+  `HTTP 201: service refused the request: Oops! Too many requests...` or
+  `HTTP 208: not a delivery the gateway can confirm: ...` -- and is logged at
+  ERROR level, so a sketch on the default log levels sees what the service
+  said.
+- **A destination whose name does not resolve stalled an ESP32 gateway on
+  every attempt** (#453). A failed lookup surfaced as `connection refused`
+  after the resolver's own patience, which this library cannot bound on ESP32,
+  and every attempt -- the origin node's retries and, since the bridge fix
+  above, the bridge's own sends -- paid it again, until relayed requests timed
+  out on their origin nodes. An ESP32 gateway now resolves the host once,
+  reports `DNS lookup failed for <host>`, and refuses that host for 60 s
+  without another lookup. ESP8266 is unchanged: its core bounds the lookup by
+  the HTTP timeout. The gateway blocking budget is unchanged.
+- **A bridge that rebooted as a regular node swallowed every Internet request
+  routed to it.** Found on the hardware rig while validating this release. A
+  bridge that reboots, crashes, loses power or is reflashed announces nothing
+  -- only a bridge stepping down in-process sends `leaving` -- so its peers
+  kept it in their bridge list for the 60 s they trust a status, and could
+  prefer it over a live bridge on RSSI. A regular node had no handler for
+  gateway requests and dropped them without a reply; each sender waited out
+  its 30 s request timeout and reported "Request timed out". Every node now
+  answers a gateway request it cannot serve with
+  `Node <id> is not an Internet gateway`; the sender forgets that node as a
+  gateway and sends again at once through the next one, without spending a
+  retry. When it knows no other gateway, the request rides the ordinary retry
+  backoff -- on the rig the live bridge was advertised half a second later --
+  and fails with `No Internet gateway available: ...` only when none appears.
+- **Mismatched log format arguments in `routePackage()`** (CodeQL
+  `cpp/wrong-type-format-argument`). A message that failed to parse was logged
+  with its `size_t` lengths through `%d`/`%u` -- the wrong width on 64-bit
+  hosts -- and with its `DeserializationError` object passed through `%u`,
+  undefined behaviour on every platform, in the ArduinoJson 7 path every
+  current build compiles as well as the legacy one CodeQL flagged.
+
+### Changed
+
+- **The mock HTTP server is now the gateway test point.** It keeps a delivery
+  ledger (`GET /requests/{tag}`) and emulates CallMeBot's status quirks
+  (`GET /callmebot/whatsapp.php`, profile chosen by `apikey`). The desktop CI
+  job starts it and `PAINLESSMESH_TESTPOINT` points the suite at it, so the
+  library's delivery verdict is checked against what the service actually did,
+  not against a table of status codes. The Alteriom farm's gateway probe serves
+  the same routes.
+- **`Mesh::sendGatewayAck()` is public and portable.** It moved from the ESP
+  gateway code into `painlessmesh::Mesh`, because every node now needs it to
+  answer a request it cannot serve.
+- **`Log()` is format-checked in the desktop build.** The test build marks it
+  printf-like, so CI's `-Wall -Werror` rejects an argument that does not match
+  its specifier. Device builds are unchanged: on ESP-IDF 5 `uint32_t` is
+  `unsigned long`, and every `%u` of a node id would warn there.
+- **`sendToInternet` example.** The startup WhatsApp retries every 30 s until
+  a gateway with Internet is known instead of firing once before a regular
+  node has joined, and the cloud endpoint moved to a `CLOUD_URL` define whose
+  placeholder is skipped with a message rather than reported as
+  `connection refused`.
+
 ## [2.0.2] - 2026-09-08
 
 Two gateway defects that reached users on 2.0.1, both in code the desktop test

package/CONTRIBUTING.md

@@ -55,6 +55,21 @@ and OTA behaviour is validated on the Alteriom hardware-in-the-loop farm; a
 maintainer runs it on a pull request by adding the `run-hil` label, and the
 release gate is three consecutive clean runs of the whole suite.
 
+### The HTTP test point
+
+`test/mock-http-server/server.py` is the controlled Internet destination for
+`sendToInternet()` tests at every level. It answers the way real services do,
+including the ways they get it wrong (its CallMeBot emulation returns refusals
+as HTTP 201 and 203, as the real API does), and it keeps a delivery ledger:
+`GET /requests/{tag}` says whether the service actually accepted a request.
+The desktop CI job starts one and exports `PAINLESSMESH_TESTPOINT`, and
+`catch_issue450_testpoint_semantics` makes real HTTP requests to it and
+requires the library's verdict to match the ledger. The farm's gateway probe
+serves the same routes with the same record shape, so a hardware row and a
+desktop scenario are measured against one source of truth. When a gateway bug
+comes in, add the service behaviour that exposed it to the server first, then
+the test that fails against it.
+
 ### Adding tests for new features
 
 1. **Unit tests**: add to `test/catch/` for new components.

package/README.md

@@ -596,9 +596,11 @@ These are the message types used by applications built on painlessMesh:
 - **Event Coordination** - Synchronized displays, distributed processing
 - **Bridge Networks** - Connect mesh to WiFi/Internet/MQTT - [📖 Bridge Guide](BRIDGE_TO_INTERNET.md)
 
-## Latest Release: v2.0.2 (September 8, 2026)
+## Latest Release: v2.0.3 (September 11, 2026)
 
-**Two gateway fixes — upgrade if any node of yours is a bridge.** On 2.0.1 a bridge could not reach the Internet through its own uplink at all (`initAsBridge()` never started the health checker that `sendToInternet()`'s local path depends on, so a bridge with no peer yet failed with "No active mesh connections"), and any request that failed *below* HTTP — refused, unresolvable, timed out — was reported to the origin node as `HTTP 65535`, a truncated `-1`, which also stopped it from being retried. Both are now asserted on the hardware rig, including a bridge with no mesh peer at all.
+**`sendToInternet()` fixes — upgrade if any node of yours is a bridge or relays to the Internet.** On 2.0.2 a bridge's own sends were refused with "No active mesh connections" for the first 30 s after `initAsBridge()`, because the health check's first probe ran while the station was still associating. The gateway also decided delivery on the HTTP status alone: CallMeBot answers a refusal with HTTP 201, so a message it refused could be reported as sent, and every failure reached the origin node as a bare number. The gateway now reads the start of the response body, counts only 200/201/202/204 without a refusing body as delivered, and hands every failure to your callback with the service's own words. A destination whose name does not resolve no longer stalls an ESP32 gateway on every attempt: it is refused for 60 s after one failed lookup. And a bridge that reboots, crashes or is reflashed as a regular node no longer swallows the requests its peers still send it for a minute: it answers that it is not a gateway, and the sender moves to the next one at once.
+
+**2.0.2 — two gateway fixes.** On 2.0.1 a bridge could not reach the Internet through its own uplink at all (`initAsBridge()` never started the health checker that `sendToInternet()`'s local path depends on, so a bridge with no peer yet failed with "No active mesh connections"), and any request that failed *below* HTTP — refused, unresolvable, timed out — was reported to the origin node as `HTTP 65535`, a truncated `-1`, which also stopped it from being retried. Both are now asserted on the hardware rig, including a bridge with no mesh peer at all.
 
 **2.0.1 — a packaging fix over 2.0.0, no library behaviour changed.** 2.0.0's installation instructions named a PlatformIO package that has no 2.0.0 (`alteriom/…` stops at 1.10.0; releases go out under `sparck75`), and its GitHub release carried no library archive because the upload was refused by an immutable release.
 

package/RELEASE_GUIDE.md

@@ -38,13 +38,23 @@ These files must always contain the same semantic version:
 - `library.properties`
 - `library.json`
 - `package.json`
+- `package-lock.json` (the root `version` and `packages[""].version`)
+- `src/AlteriomPainlessMesh.h` (the version string and the MAJOR/MINOR/PATCH
+  defines a sketch compiles against)
+- `doxygen/Doxyfile` (`PROJECT_NUMBER`, the number on every generated API page)
 
-Use the repository script to change them together:
+Use the repository script to change them together; it updates all six and then
+verifies they agree:
 
 ```bash
 ./scripts/bump-version.sh patch
+./scripts/bump-version.sh patch 2.0.3 --yes   # no prompt, for CI or an agent
 ```
 
+`jq` is used when it is installed and awk otherwise, and both paths change only
+the package's own version — never a dependency range. `test/ci/test_bump_version.sh`
+holds that, and the Code Quality job runs it.
+
 You may use `minor`, `major`, or an explicit version when the release plan
 requires it. Version 2.0 patch releases must remain wire-compatible with the
 2.0 protocol.

package/examples/sendToInternet/README.md

@@ -187,10 +187,10 @@ The callback provides `httpStatus` to indicate the result:
 
 **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**.
+⚠️ **The status alone does not say whether WhatsApp got the message.** CallMeBot answers a refusal (for example "Too many requests") with HTTP 201 or HTTP 203, the same error page under both. The gateway therefore reads the start of the response body: a 2xx whose body says the service refused the request is reported as a failure, with the service's own words in the callback's `error` string, and HTTP 203 stays a failure because a proxy, not the WhatsApp API, may have answered. If your callback prints `HTTP 201: service refused the request: Oops! Too many requests...`, that is CallMeBot talking, and the message was **NOT delivered**. Likewise `HTTP 208: not a delivery the gateway can confirm: ...`: CallMeBot answers 208 to messages that never arrive (issues #450 and #452), so only 200, 201, 202 and 204 with a clean body are reported as sent, and the rest of the line is whatever the service said.
+
+Also replace `CLOUD_URL` at the top of the sketch: the placeholder `api.example.com` does not resolve, and until you change it the sketch skips the cloud send and says so instead of reporting `connection refused` every minute.
 
 ## Files
 

package/examples/sendToInternet/sendToInternet.ino

@@ -74,6 +74,19 @@
 #define WHATSAPP_PHONE  "+1234567890"    // Your phone number with country code
 #define WHATSAPP_APIKEY "your_api_key"   // Your Callmebot API key
 
+// ============================================
+// Cloud API Configuration
+// ============================================
+// The endpoint the periodic sensor readings are POSTed to. Replace it with
+// your own; the placeholder below does not resolve, so until you do the
+// sketch skips the cloud send and says so rather than reporting
+// "connection refused" every minute (issue #450).
+// Example endpoints:
+// - ThingsBoard: "https://demo.thingsboard.io/api/v1/YOUR_TOKEN/telemetry"
+// - AWS IoT:     "https://YOUR_ENDPOINT.iot.us-east-1.amazonaws.com/topics/sensors"
+// - Custom API:  "https://api.yourserver.com/sensors/data"
+#define CLOUD_URL       "https://api.example.com/sensors"
+
 // ============================================
 // Sensor Simulation Configuration
 // ============================================
@@ -115,6 +128,15 @@ String urlEncode(const String& str);
 // Task to periodically send sensor data (simulated)
 Task taskSendSensorData(60000, TASK_FOREVER, &sendSensorDataToCloud);
 
+// The startup WhatsApp used to be a single 30 s one-shot. A regular node that
+// took longer than that to find the mesh -- following a bridge to another
+// channel takes about a minute -- fired it with no gateway in sight and never
+// tried again (issue #450). It now retries until a gateway with Internet is
+// known, then disables itself.
+void sendStartupAlert();
+Task taskStartupAlert(30000, TASK_FOREVER, &sendStartupAlert);
+String startupMsg;
+
 // ============================================
 // URL Encoding Helper
 // ============================================
@@ -184,13 +206,12 @@ 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.
+  //
+  // The gateway reads the response body, not only the status: CallMeBot
+  // answers a refusal ("Too many requests") with HTTP 201 or 203, so a 2xx
+  // alone proves nothing. A refusal arrives here as success=false with the
+  // service's own words in `error`; HTTP 203 stays a failure because a proxy,
+  // not WhatsApp, may have answered.
   uint32_t msgId = mesh.sendToInternet(
     url,
     "",  // No payload needed for GET request - params are in URL
@@ -249,14 +270,13 @@ void sendSensorDataToCloud() {
     return;
   }
   
-  // Send to cloud API (replace with your actual endpoint)
-  // Example endpoints:
-  // - ThingsBoard: "https://demo.thingsboard.io/api/v1/YOUR_TOKEN/telemetry"
-  // - AWS IoT: "https://YOUR_ENDPOINT.iot.us-east-1.amazonaws.com/topics/sensors"
-  // - Custom API: "https://api.yourserver.com/sensors/data"
-  
-  String cloudUrl = "https://api.example.com/sensors";  // Replace with your endpoint
-  
+  // Send to the cloud API configured at the top of the sketch
+  String cloudUrl = CLOUD_URL;
+  if (cloudUrl.indexOf("example.com") >= 0) {
+    Serial.println("   (CLOUD_URL is still the placeholder; set your endpoint to send readings)");
+    return;
+  }
+
   uint32_t msgId = mesh.sendToInternet(
     cloudUrl,
     payload,
@@ -276,6 +296,21 @@ void sendSensorDataToCloud() {
 // Mesh Callbacks
 // ============================================
 
+/**
+ * Send the startup notification once a gateway with Internet is known.
+ *
+ * Runs every 30 s from taskStartupAlert until it has handed the message to
+ * sendToInternet(), then disables itself.
+ */
+void sendStartupAlert() {
+  if (!mesh.hasInternetConnection()) {
+    Serial.println("(startup WhatsApp waiting for a gateway with Internet; retrying in 30 s)");
+    return;
+  }
+  sendAlertToWhatsApp(startupMsg);
+  taskStartupAlert.disable();
+}
+
 void receivedCallback(uint32_t from, String& msg) {
   Serial.printf("📨 Received from %u: %s\n", from, msg.c_str());
 }
@@ -347,14 +382,14 @@ void setup() {
   Serial.printf("Is Bridge: %s\n", mesh.isBridge() ? "YES" : "NO");
   Serial.println("================================================\n");
   
-  // Send a startup notification via WhatsApp (demonstrates sendToInternet)
-  String startupMsg = "🚀 Node " + String(mesh.getNodeId()) + " started!";
-  
-  // Delay to allow mesh to connect first
-  Serial.println("Will attempt to send startup WhatsApp in 30 seconds...\n");
-  mesh.addTask([startupMsg]() {
-    sendAlertToWhatsApp(startupMsg);
-  }, 30000);  // 30 second delay
+  // Send a startup notification via WhatsApp (demonstrates sendToInternet).
+  // First attempt in 30 s, then every 30 s until a gateway with Internet is
+  // known: a bridge can use its own uplink at once, a regular node has to
+  // find the mesh first.
+  startupMsg = "🚀 Node " + String(mesh.getNodeId()) + " started!";
+  Serial.println("Will send the startup WhatsApp as soon as a gateway with Internet is known (first try in 30 s)...\n");
+  userScheduler.addTask(taskStartupAlert);
+  taskStartupAlert.enableDelayed();
 }
 
 // ============================================

package/library.json

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

package/library.properties

@@ -1,5 +1,5 @@
 name=Alteriom PainlessMesh
-version=2.0.2
+version=2.0.3
 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": "2.0.2",
+  "version": "2.0.3",
   "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 "2.0.2"
+#define ALTERIOM_PAINLESS_MESH_VERSION "2.0.3"
 #define ALTERIOM_PAINLESS_MESH_VERSION_MAJOR 2
 #define ALTERIOM_PAINLESS_MESH_VERSION_MINOR 0
-#define ALTERIOM_PAINLESS_MESH_VERSION_PATCH 2
+#define ALTERIOM_PAINLESS_MESH_VERSION_PATCH 3
 
 /**
  * @brief Library description and usage information

package/src/arduino/wifi.hpp

@@ -2721,54 +2721,53 @@ class Mesh : public painlessmesh::Mesh<Connection> {
   /**
    * Helper method to send gateway acknowledgment
    */
-  void sendGatewayAck(
-      const gateway::GatewayDataPackage& request, bool success,
-      uint16_t httpStatus, const TSTRING& error,
-      std::shared_ptr<Connection> ingressConnection = nullptr) {
-    using namespace logger;
-
-    gateway::GatewayAckPackage ack;
-    ack.from = this->nodeId;
-    ack.dest = request.originNode;
-    ack.messageId = request.messageId;
-    ack.originNode = request.originNode;
-    ack.success = success;
-    ack.httpStatus = httpStatus;
-    ack.error = error;
-    ack.timestamp = this->getNodeTime();
-
-    if (request.originNode == this->nodeId) {
-      protocol::Variant variant(&ack);
-      this->callbackList.execute(protocol::GATEWAY_ACK, variant, nullptr, 0);
-      Log(COMMUNICATION,
-          "Completed local GATEWAY_ACK (success=%d, http=%d)\n", success,
-          httpStatus);
-      return;
-    }
+  /** Hosts that recently failed to resolve; fed on ESP32 only, see the
+   *  GATEWAY_DATA handler. */
+  gateway::NegativeDnsCache negativeDns;
 
-    auto conn = router::findRoute<Connection>((*this), request.originNode);
-    if (!conn && ingressConnection) {
-      // A newly promoted gateway can receive data before its NodeTree has
-      // converged enough for findRoute() to resolve the request origin.  The
-      // ingress connection is nevertheless a valid reverse path: the request
-      // just arrived through it and every intermediate node can continue
-      // routing the addressed acknowledgment toward originNode.
-      conn = ingressConnection;
-      Log(COMMUNICATION,
-          "Routing GATEWAY_ACK to node %u through request ingress while "
-          "topology converges\n",
-          request.originNode);
-    }
-    if (conn) {
-      protocol::Variant variant(&ack);
-      router::send(std::move(variant), conn);
-      Log(COMMUNICATION, "Sent GATEWAY_ACK to node %u (success=%d, http=%d)\n",
-          request.originNode, success, httpStatus);
-    } else {
-      Log(ERROR, "Failed to send GATEWAY_ACK: no route to node %u\n",
-          request.originNode);
+#if defined(ESP32) || defined(ESP8266)
+  /**
+   * Read the start of an HTTP response body, bounded in bytes and in time
+   *
+   * The gateway used to discard the body, so a service that answers a refusal
+   * with a 2xx (CallMeBot, issue #450) was reported as delivered, and a
+   * failure reached the origin node as a bare status. When the length is
+   * known and small the whole body is taken; otherwise up to maxBytes are
+   * read from the stream, waiting at most GATEWAY_RESPONSE_HEAD_TIMEOUT_MS,
+   * which keeps a large or chunked page from eating the heap or the
+   * cooperative scheduler.
+   */
+  static TSTRING readResponseHead(HTTPClient& http, size_t maxBytes) {
+    const int size = http.getSize();
+    if (size >= 0 && static_cast<size_t>(size) <= maxBytes) {
+      return http.getString();
+    }
+    TSTRING head;
+    WiFiClient* stream = http.getStreamPtr();
+    if (stream == nullptr) return head;
+    const uint32_t deadline =
+        millis() + gateway::GATEWAY_RESPONSE_HEAD_TIMEOUT_MS;
+    while (head.length() < maxBytes &&
+           static_cast<int32_t>(deadline - millis()) > 0) {
+      int available = stream->available();
+      if (available <= 0) {
+        if (!stream->connected()) break;
+        delay(1);
+        continue;
+      }
+      while (available-- > 0 && head.length() < maxBytes) {
+        const int c = stream->read();
+        if (c < 0) break;
+        head += static_cast<char>(c);
+      }
     }
+    return head;
   }
+#endif
+
+  // sendGatewayAck() is portable and lives in painlessmesh::Mesh
+  // (mesh.hpp): every node needs it, not only a gateway, to answer a
+  // request it cannot serve.
 
   /**
    * Initialize gateway Internet handler
@@ -2873,6 +2872,49 @@ class Mesh : public painlessmesh::Mesh<Connection> {
           }
 
 #if defined(ESP32) || defined(ESP8266)
+#ifdef ESP32
+          // A destination whose name failed to resolve is refused for
+          // GATEWAY_DNS_NEGATIVE_TTL_MS without another lookup (issue #453).
+          // HTTPClient reports a failed lookup as "connection refused" after
+          // the resolver's own patience -- on ESP32 not boundable by this
+          // library -- and it did so on every attempt: the origin node's
+          // retries and, since #451, the bridge's own sends each paid it, and
+          // the scheduler stalled long enough for relayed requests to time
+          // out on their origin nodes. Resolving here, once, names the real
+          // failure and caps the stall to one lookup per TTL per host.
+          // ESP32 only: the ESP8266 core bounds HTTPClient's own lookup by the
+          // HTTP timeout, and a second bounded wait would not fit the
+          // blocking budget.
+          const TSTRING host = gateway::hostFromUrl(pkg.destination);
+          if (host.length() > 0 && !gateway::looksLikeIpLiteral(host)) {
+            uint32_t failedAgoMs = 0;
+            if (negativeDns.isFailing(host, millis(), &failedAgoMs)) {
+              char dnsBuf[160];
+              snprintf(dnsBuf, sizeof(dnsBuf),
+                       "DNS lookup for %s failed %lus ago; not retried for "
+                       "another %lus",
+                       host.c_str(),
+                       static_cast<unsigned long>(failedAgoMs / 1000),
+                       static_cast<unsigned long>(
+                           (gateway::GATEWAY_DNS_NEGATIVE_TTL_MS - failedAgoMs) /
+                           1000));
+              Log(ERROR, "%s\n", dnsBuf);
+              finish(false, 0, TSTRING(dnsBuf));
+              return true;
+            }
+            IPAddress resolved;
+            if (WiFi.hostByName(host.c_str(), resolved) != 1) {
+              negativeDns.remember(host, millis());
+              char dnsBuf[160];
+              snprintf(dnsBuf, sizeof(dnsBuf), "DNS lookup failed for %s",
+                       host.c_str());
+              Log(ERROR, "%s\n", dnsBuf);
+              finish(false, 0, TSTRING(dnsBuf));
+              return true;
+            }
+          }
+#endif  // ESP32
+
           // Make HTTP/HTTPS request
           HTTPClient http;
           http.setTimeout(GATEWAY_HTTP_TIMEOUT_MS);
@@ -2925,51 +2967,70 @@ class Mesh : public painlessmesh::Mesh<Connection> {
             httpCode = http.GET();
           }
 
-          // Only specific 2xx status codes indicate genuine success:
-          // 200 OK, 201 Created, 202 Accepted, 204 No Content.
-          //
-          // 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).
+          // A 2xx is the origin's acceptance, except 203 (a proxy transformed
+          // the response) and except when the body says the service refused
+          // the request: CallMeBot answers "Too many requests" under 201 and
+          // 203 (issue #450). The body is therefore read -- bounded -- before
+          // classifying, and it is what the origin node is told on failure.
           //
           // 3xx redirects are not automatically followed.
           //
           // The classification lives in painlessmesh::gateway so the desktop
           // test suite can exercise it; this file is ESP-only and never
           // compiled by the Catch2 build.
-          const auto outcome = gateway::classifyHttpResult(httpCode);
+          TSTRING responseHead;
+          if (httpCode > 0) {
+            responseHead =
+                readResponseHead(http, gateway::GATEWAY_RESPONSE_HEAD_BYTES);
+          }
+          const auto outcome =
+              gateway::classifyHttpResult(httpCode, responseHead);
           success = outcome.success;
 
           if (!outcome.transportError) {
+            char errorBuf[192];
+            const char* reason = outcome.reason.c_str();
+            const char* sep = outcome.reason.length() > 0 ? ": " : "";
             if (success) {
               Log(COMMUNICATION, "HTTP request completed: code=%d\n", httpCode);
-            } else if (httpCode >= 200 && httpCode < 300) {
-              // Other 2xx codes - ambiguous success
-              // HTTP 203 is retryable, so log at COMMUNICATION level to reduce noise
-              char errorBuf[128];
-              snprintf(errorBuf, sizeof(errorBuf), 
-                      "Ambiguous response - HTTP %d may indicate cached/proxied response, not actual delivery", 
-                      httpCode);
+            } else if (outcome.refusedByBody) {
+              // Success-class status, refusing body. Not retryable: the
+              // service answered, and the origin node gets its words.
+              snprintf(errorBuf, sizeof(errorBuf),
+                       "HTTP %d: service refused the request%s%s", httpCode,
+                       sep, reason);
+              error = TSTRING(errorBuf);
+              Log(ERROR, "HTTP request refused by the service: %s\n", errorBuf);
+            } else if (outcome.unverifiedStatus) {
+              // A 2xx outside 200/201/202/204. CallMeBot answers 208 to a
+              // message that never arrives (issue #452), so this is a
+              // failure, and the body -- the only place the service says
+              // what it did -- goes to the origin node and to the log at
+              // ERROR level, where a sketch running the default levels
+              // sees it. 203 stays retryable; the rest are final.
+              snprintf(errorBuf, sizeof(errorBuf),
+                       "HTTP %d: not a delivery the gateway can confirm%s%s",
+                       httpCode, sep, reason);
               error = TSTRING(errorBuf);
-              Log(COMMUNICATION, "HTTP request ambiguous: code=%d (treated as failure, will retry)\n", httpCode);
+              Log(ERROR, "HTTP response unverified: %s\n", errorBuf);
             } else if (httpCode >= 500 && httpCode < 600) {
               // 5xx server errors are retryable, log at COMMUNICATION level
-              char errorBuf[32];
-              snprintf(errorBuf, sizeof(errorBuf), "HTTP %d", httpCode);
+              snprintf(errorBuf, sizeof(errorBuf), "HTTP %d%s%s", httpCode, sep,
+                       reason);
               error = TSTRING(errorBuf);
               Log(COMMUNICATION, "HTTP server error: code=%d (will retry)\n", httpCode);
             } else if (httpCode == 429) {
               // HTTP 429 rate limit is retryable, log at COMMUNICATION level
-              char errorBuf[32];
-              snprintf(errorBuf, sizeof(errorBuf), "HTTP %d", httpCode);
+              snprintf(errorBuf, sizeof(errorBuf), "HTTP %d%s%s", httpCode, sep,
+                       reason);
               error = TSTRING(errorBuf);
               Log(COMMUNICATION, "HTTP rate limit: code=%d (will retry)\n", httpCode);
             } else {
               // 1xx, 3xx, 4xx (except 429) - non-retryable, log at ERROR level
-              char errorBuf[32];
-              snprintf(errorBuf, sizeof(errorBuf), "HTTP %d", httpCode);
+              snprintf(errorBuf, sizeof(errorBuf), "HTTP %d%s%s", httpCode, sep,
+                       reason);
               error = TSTRING(errorBuf);
-              Log(ERROR, "HTTP request failed: code=%d\n", httpCode);
+              Log(ERROR, "HTTP request failed: %s\n", errorBuf);
             }
           } else {
             // Network errors (httpCode <= 0) are retryable but indicate serious issues
@@ -2993,6 +3054,20 @@ class Mesh : public painlessmesh::Mesh<Connection> {
         });
   }
 
+  /**
+   * The station just got an IP. On a node that runs the Internet health
+   * check -- a bridge or a shared gateway, whose station is the manual router
+   * link -- the last probe most likely ran during association and failed,
+   * and the next is a full interval away (issue #450). Probe again now, from
+   * the scheduler rather than the Wi-Fi event task, so hasLocalInternet()
+   * and the bridge's own sends stop waiting out the interval. A regular
+   * node's mesh station never enables the check and is left alone.
+   */
+  void probeUplinkAfterAssociation() {
+    if (!this->isInternetHealthCheckEnabled() || !stationScan.manual) return;
+    this->addTask([this]() { this->checkInternetNow(); });
+  }
+
   void eventHandleInit() {
     using namespace logger;
     // Where the station scan learns the channel the mesh is rooted on.
@@ -3101,6 +3176,7 @@ class Mesh : public painlessmesh::Mesh<Connection> {
             this->stationScan.stationAttemptOver();
             this->stationScan.stationUp();
             this->tcpConnect();  // Connect to TCP port
+            this->probeUplinkAfterAssociation();
             this->semaphoreGive();
           }
         },
@@ -3137,6 +3213,7 @@ class Mesh : public painlessmesh::Mesh<Connection> {
           this->stationScan.stationAttemptOver();
           this->stationScan.stationUp();
           this->tcpConnect();  // Connect to TCP port
+          this->probeUplinkAfterAssociation();
         });
 #endif  // ESP32
     return;

package/src/painlessmesh/callback.hpp

@@ -76,6 +76,13 @@ class PackageCallbackList {
     return size;
   }
 
+  /** How many callbacks are registered for one package id. */
+  size_t count(int id) {
+    auto generation = clearPending ? pendingCallbackMap : callbackMap;
+    auto it = generation->find(id);
+    return it == generation->end() ? 0 : it->second.size();
+  }
+
   void clear() {
     if (dispatchDepth > 0) {
       clearPending = true;