merchant

commit b151689ed9f0770c2a2a31569493b00f7664916f
parent 135ee372150641acfed4ef5ee4a396e3910a321b
Author: Christian Grothoff <christian@grothoff.org>
Date:   Fri, 14 Aug 2026 17:47:17 +0200

disambiguate return values

Diffstat:
M
src/backend/taler-merchant-httpd_post-challenge-ID.c
 | 
44
++++++++++++++++++++++++++++++++++----------

1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/src/backend/taler-merchant-httpd_post-challenge-ID.c b/src/backend/taler-merchant-httpd_post-challenge-ID.c
@@ -291,14 +291,39 @@ respond_with_error (struct MfaState *mfa,
 
 
 /**
+ * Did a challenge transmission helper report that the challenge was
+ * transmitted?
+ *
+ * Exit code 0 means the challenge was confirmed to have reached the address.
+ * The 200-210 band means a service accepted it for delivery without confirming
+ * that it arrived: 201 accepted by the provider, 202 suppressed as a duplicate
+ * of a message already in flight.
+ *
+ * The band deliberately does not start at 1: libgnunetutil reports a helper it
+ * failed to exec() as exit code 1, and that must not be mistaken for a
+ * delivery.
+ *
+ * @param exit_code exit status of the helper, which must have exited normally
+ * @return true if the challenge was transmitted
+ */
+static bool
+helper_reported_success (unsigned long int exit_code)
+{
+  return (0 == exit_code) ||
+         ( (exit_code >= 200) &&
+           (exit_code <= 210) );
+}
+
+
+/**
  * Map the exit status of a challenge transmission helper onto an HTTP status
  * and error code.
  *
  * The helpers shipped with Challenger use a banded exit-code scheme documented
- * in challenger-send-sms(1): anything below 10 means the challenge was
- * transmitted, 10-19 blames the address configured for this step, 20-29 is a
- * recipient that is temporarily unreachable, 30-39 is the transmission
- * provider and 40-49 is our own configuration.
+ * in challenger-send-sms(1): 0 and 200-210 mean the challenge was transmitted
+ * (see #helper_reported_success()), 10-19 blames the address configured for
+ * this step, 20-29 is a recipient that is temporarily unreachable, 30-39 is
+ * the transmission provider and 40-49 is our own configuration.
  *
  * Codes we do not recognise are reported as an upstream failure rather than
  * blamed on the client, so that a helper predating this scheme -- which used
@@ -312,12 +337,14 @@ static enum TALER_ErrorCode
 classify_helper_status (unsigned long int exit_code,
                         unsigned int *http_status)
 {
-  if (exit_code < 20)
+  if ( (exit_code >= 10) &&
+       (exit_code < 20) )
   {
     *http_status = MHD_HTTP_BAD_REQUEST;
     return TALER_EC_MERCHANT_TAN_ADDRESS_UNUSABLE;
   }
-  if (exit_code < 30)
+  if ( (exit_code >= 20) &&
+       (exit_code < 30) )
   {
     *http_status = MHD_HTTP_SERVICE_UNAVAILABLE;
     return TALER_EC_MERCHANT_TAN_ADDRESS_UNREACHABLE;
@@ -447,11 +474,8 @@ transmission_done_cb (void *cls,
   }
   mfa->exited = (GNUNET_OS_PROCESS_EXITED == type);
   mfa->exit_code = exit_code;
-  /* Exit codes below 10 all mean the challenge was transmitted: 0 confirmed
-     on the handset, 1 accepted by the provider, 2 suppressed as a duplicate
-     of a message already in flight.  See challenger-send-sms(1). */
   mfa->send_ok = (mfa->exited &&
-                  (exit_code < 10) );
+                  helper_reported_success (exit_code));
   if (! mfa->send_ok)
     GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
                 "MFA helper failed with status %d/%u\n",