Name the municipality behind a CEP that does not existHEADv0.2.0main

A CEP that fails at the checkout is almost never a random number. It is
a shopper who knows perfectly well which town they live in and got a
digit wrong, most often by reaching for the -000 that 957 municipalities
never received. The API now names the municipality such a number would
have belonged to, in the body of its own 404, so the message can say
"that would be in Areal/RJ, which has CEPs from 25845-001 to 25849-899"
instead of leaving the shopper at a dead end with nothing to act on.

It stays an error. Nothing from it is written into a checkout field, on
either checkout and in either lookup mode: a CEP that does not exist has
no address, and filling one in from the municipality behind it means a
parcel delivered to the wrong town and a chargeback behind that. The one
module that reads the 404 body hands its callers a finished sentence and
never the data itself, so there is no shape in which it could leak into
a field later. The two CEPs quoted are the lowest and the highest that
really exist there, never a list and never a suggestion, because the
range is sparse enough that a number out of the middle of it would most
likely not exist either.

The widget correctly throws its 404 away without reading it, so the body
is fetched once more, on the miss path only and once per CEP. In proxy
mode PHP passes the municipality through with the 404 and caches it with
the miss, which is what keeps the two modes indistinguishable from the
browser. Anything missing or misshapen falls back to the message the
plugin has always shown.

1 files changed, 38 insertions, 1 deletions

diff --git a/assets/js/cepis-woocommerce-blocks.js b/assets/js/cepis-woocommerce-blocks.js
index bcbab93..4f4e2e3 100644
--- a/assets/js/cepis-woocommerce-blocks.js
+++ b/assets/js/cepis-woocommerce-blocks.js
@@ -131,6 +131,37 @@
   }
 
   /**
+   * Say which municipality a CEP that does not exist would have been in.
+   *
+   * Replaces the notice already on screen — same id, so the block swaps the
+   * text rather than stacking a second error. The failure is reported
+   * immediately and refined a round trip later, because making the shopper wait
+   * on a second request before being told anything at all is worse than the
+   * message improving under them.
+   *
+   * Nothing here goes near `apply()`. A CEP the Correios do not have has no
+   * address, and the municipality in a 404 is a guess about which digit went
+   * wrong, not a place to ship to.
+   *
+   * @param {string} name Section name, `shipping` or `billing`.
+   * @param {string} digits The CEP that was not found.
+   * @param {string} shown The message already in the notice area.
+   */
+  function explain(name, digits, shown) {
+    var helper = window.cepisWooCommerceFaixa;
+
+    if (!helper) {
+      return;
+    }
+
+    helper.message(digits, shown, function (message) {
+      if (message !== shown && progress[name].cep === digits) {
+        announce(message);
+      }
+    });
+  }
+
+  /**
    * Write a resolved address into the store.
    *
    * @param {string} name Section name, `shipping` or `billing`.
@@ -185,7 +216,13 @@
         if (progress[name].cep !== digits || error.code === "aborted") {
           return;
         }
-        announce(config.messages[error.code] || error.message);
+
+        var shown = config.messages[error.code] || error.message;
+        announce(shown);
+
+        if (error.code === "not_found") {
+          explain(name, digits, shown);
+        }
       },
     );
   }