@riocrypto/common-server 1.0.2879 → 1.0.2880

package/build/helpers/get-processor.js

@@ -31,8 +31,11 @@ const getProcessor = ({ country, fiat, side, isBinanceRFQ, routingConfig, disabl
     ];
     // Applied only inside the branches that genuinely have more than one rail, so
     // a stray rule cannot hijack structural routing (COP, USD in the US or Mexico)
-    // or bypass the country checks below. Returns undefined when no rule is
-    // configured, leaving the corridor's structural default in charge.
+    // or bypass the country checks below. Answers even when no rule is configured,
+    // because the corridor default is only safe to use once the rails the customer
+    // has switched off are out of the running. Undefined is left for the one case
+    // that genuinely belongs to structural routing: a custom Rio bank account whose
+    // rail we do not know.
     const trySplit = () => {
         const routed = (0, resolve_processor_1.resolveProcessor)({
             country,
@@ -62,10 +65,11 @@ const getProcessor = ({ country, fiat, side, isBinanceRFQ, routingConfig, disabl
         }
         return undefined;
     };
-    // The rail this corridor runs on when no split decides it, from the one table
-    // the routing editor reads as well - so the page can name the rail an empty
-    // split leaves in charge. Throwing on a missing entry keeps the two honest: a
-    // corridor that gets this far has to have a default.
+    // The rail a corridor with nothing to decide runs on, from the one table the
+    // routing editor reads as well, so the page can name it. Reached by corridors
+    // with a single rail, and by the unknown-rail custom account case. Throwing on
+    // a missing entry keeps the two honest: a corridor that gets this far has to
+    // have a default.
     const structural = () => {
         const fallback = (0, common_1.getDefaultProcessor)(country, fiat, purpose, excludedProcessors);
         if (!fallback) {

package/build/helpers/resolve-processor.d.ts

@@ -13,6 +13,6 @@ export interface ResolveProcessorParams {
 }
 export interface ResolveProcessorResult {
     processor?: Processor;
-    reason: "customRioBankAccount" | "customRioBankAccountWithoutRail" | "split" | "onlyCandidate" | "enabledRailWithoutShare" | "noRuleConfigured" | "noEligibleCandidate" | "noEnabledCandidate";
+    reason: "customRioBankAccount" | "customRioBankAccountWithoutRail" | "split" | "onlyCandidate" | "enabledRailWithoutShare" | "noEligibleCandidate" | "noEnabledCandidate";
 }
 export declare const resolveProcessor: ({ country, fiat, purpose, routingConfig, excludedProcessors, disabledProcessors, customRioBankAccount, randomSeed, }: ResolveProcessorParams) => ResolveProcessorResult;

package/build/helpers/resolve-processor.js

@@ -23,11 +23,11 @@ const pickByShare = (candidates, position) => {
 // from the configured split.
 //
 // A percentage divides volume between the rails that are actually available to
-// the customer; it is not a switch. A rail left at zero, or left out of the rule
-// altogether, still takes their orders when it is the only one they have left
-// enabled, which is why the candidate set comes from the corridor rather than
-// from the rule. Switching a rail off is the only way to keep an order away from
-// it.
+// the customer; it is not a switch. A rail left at zero, left out of the rule, or
+// belonging to a corridor with no rule at all still takes their orders when it is
+// the only one they have left enabled, which is why the candidate set comes from
+// the corridor rather than from the rule. Switching a rail off is the only way to
+// keep an order away from it.
 //
 // Does no IO of its own - the routing config and the user's readiness are passed
 // in - and the only nondeterminism is the per-order roll, which a caller can
@@ -73,10 +73,12 @@ const resolveProcessor = ({ country, fiat, purpose, routingConfig, excludedProce
         }
         return { processor, reason: "customRioBankAccount" };
     }
+    // An absent rule is read as every rail at zero rather than as a reason to stop.
+    // Bailing out here would hand the decision to the structural default, which
+    // knows nothing about which rails the customer accepts, and every corridor is
+    // ruleless until an admin first saves one - as is any corridor whose shares
+    // were all cleared, since the settings page stores that as no rule at all.
     const rule = getRule(routingConfig, country, fiat, purpose);
-    if (!rule) {
-        return { reason: "noRuleConfigured" };
-    }
     // Starts from the corridor's rails rather than from the rails the rule names,
     // because a percentage decides how volume is divided between the rails a
     // customer can use - it is not what makes a rail usable. Also drops any share
@@ -91,16 +93,20 @@ const resolveProcessor = ({ country, fiat, purpose, routingConfig, excludedProce
         return { reason: "noEnabledCandidate" };
     }
     const shares = candidates
-        .map((processor) => ({
-        processor,
-        percentage: Number(rule.percentages[processor]) || 0,
-    }))
+        .map((processor) => {
+        var _a;
+        return ({
+            processor,
+            percentage: Number((_a = rule === null || rule === void 0 ? void 0 : rule.percentages) === null || _a === void 0 ? void 0 : _a[processor]) || 0,
+        });
+    })
         .filter((candidate) => candidate.percentage > 0);
-    // None of the rails this customer can use carries a share, so there is no split
-    // to draw from. Refusing the order would read a zero as "never use this rail",
-    // when all it says is where volume goes while there is somewhere else to send
-    // it. Prefers the corridor default and otherwise the corridor's own order, so
-    // the rail a customer in this position gets is predictable rather than rolled.
+    // None of the rails this customer can use carries a share - or no rule is
+    // configured at all - so there is no split to draw from. Refusing the order
+    // would read a zero as "never use this rail", when all it says is where volume
+    // goes while there is somewhere else to send it. Prefers the corridor default
+    // and otherwise the corridor's own order, so the rail a customer in this
+    // position gets is predictable rather than rolled.
     if (!shares.length) {
         const fallback = (0, common_1.getDefaultProcessor)(country, fiat, purpose, excludedProcessors);
         return {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@riocrypto/common-server",
-  "version": "1.0.2879",
+  "version": "1.0.2880",
   "description": "",
   "main": "./build/index.js",
   "types": "./build/index.d.ts",