exchange

commit 19cc785bca595de40fb1bf0ba06edbc13c30e758
parent e1d401aa0754b9ef5fb228cc555bb4be278c18d6
Author: Christian Grothoff <christian@grothoff.org>
Date:   Sun, 11 Oct 2026 14:41:22 +0200

make sure to return out_final_expiration to indicate failure if we hit an error case

Diffstat:
M
src/exchangedb/do_reserve_open.sql
 | 
22
++++++++++++++++++++--

1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/exchangedb/do_reserve_open.sql b/src/exchangedb/do_reserve_open.sql
@@ -123,8 +123,18 @@ THEN
   -- Just below TALER_AMOUNT_MAX_VALUE, the largest amount the C layer parses.
   out_open_cost.val=4503599627370495;
   out_open_cost.frac=99999999;
-  out_final_expiration=my_expiration_date;
   out_no_funds=FALSE;
+  -- We must return a failure, which the C layer detects by the returned
+  -- expiration being below the desired expiration.  Returning
+  -- my_expiration_date here would be at or above the desired expiration
+  -- and thus be reported as a successful "reserve opened" (200 OK) even
+  -- though the UPDATE below never ran.
+  IF (reserve.expiration_date >= in_desired_expiration)
+  THEN
+    out_final_expiration = 0;
+  ELSE
+    out_final_expiration = reserve.expiration_date;
+  END IF;
   RAISE NOTICE 'requested reserve lifetime or purse limit out of range';
   RETURN;
 END IF;
@@ -145,8 +155,16 @@ THEN
     -- its own.
     out_open_cost.val=4503599627370495;
     out_open_cost.frac=99999999;
-    out_final_expiration=my_expiration_date;
     out_no_funds=FALSE;
+    -- As above: the failure must be signalled by an expiration below the
+    -- desired expiration, or the C layer reports 200 OK for a reserve
+    -- that was never opened.
+    IF (reserve.expiration_date >= in_desired_expiration)
+    THEN
+      out_final_expiration = 0;
+    ELSE
+      out_final_expiration = reserve.expiration_date;
+    END IF;
     RAISE NOTICE 'arithmetic issue computing amount';
   RETURN;
   END IF;