badgr-cli 1.1.4 → 1.1.6

package/src/fallback.js

@@ -31,7 +31,7 @@ export class CapacityError extends Error {
 }
 
 /**
- * Call an API endpoint with automatic tier-2 expansion when tier-1 fails.
+ * Submit one deployment. Provider and tier fallback are backend-owned.
  * Returns the deployment object on success.
  * Throws CapacityError (pre-formatted for display) on unrecoverable failure.
  * Re-throws payment errors (err.isPaymentRequired) for callers to handle.
@@ -42,18 +42,11 @@ export class CapacityError extends Error {
  * @param {string}   effectiveTier
  * @param {object}   chalk
  * @param {object}   labels            - { thing: 'job'|'endpoint', cmd: 'badgr run'|'badgr serve' }
- * @param {object}   [opts]
- * @param {boolean}  [opts.allowTier2Fallback=true] - set false to disable tier-2 expansion
- * @param {boolean}  [opts.singleAttempt=false] - set true to skip both the same-tier
- *   provider retry and tier-2 expansion, failing immediately on the first error
- *   (badgr run --smoke's "one attempt" guarantee)
  */
-export async function callWithFallback(endpoint, callOpts, buildBody, effectiveTier, chalk, labels, opts = {}) {
+export async function callWithFallback(endpoint, callOpts, buildBody, effectiveTier, chalk, labels) {
   const { callApi } = await import('./api.js');
   const thing = labels?.thing ?? 'job';
   const cmd   = labels?.cmd   ?? 'badgr run';
-  const singleAttempt = opts.singleAttempt === true;
-  const allowTier2Fallback = !singleAttempt && opts.allowTier2Fallback !== false; // default true
 
   // 220s: comfortably above backend's BADGR_PROVISION_TIMEOUT_SECONDS (default
   // 200s, itself set above deployment_service.py's 180s routing-search
@@ -122,31 +115,58 @@ export async function callWithFallback(endpoint, callOpts, buildBody, effectiveT
     firstErr = err;
   }
 
-  const d = firstErr.errorData;
-
-  // Provider retry: PROVISIONING_FAILED means the selected provider couldn't launch the slot.
-  // Retry once with prefer_different_provider so the backend routes to a different provider
-  // (e.g. RunPod failed → try Vast.ai or Hyperstack) within the same max_cost budget.
-  if (!singleAttempt && (d?.code === 'PROVISIONING_FAILED' || d?.code === 'PROVIDER_ADAPTER_ERROR')) {
-    console.log(chalk.dim('\n  Provider unavailable — trying alternative provider...\n'));
-    try {
-      const retryBody = { ...buildBody(), prefer_different_provider: true };
-      return await attempt(retryBody);
-    } catch (retryErr) {
-      if (retryErr.isPaymentRequired) throw retryErr;
-      firstErr = retryErr;
+  // A stale/expired/revoked API key is not capacity trouble — the request
+  // never got past auth, so retrying against another provider or expanding
+  // to tier-2 can't help and just prints misleading "expanding search"
+  // language over a problem those retries cannot fix. Short-circuit before
+  // any fallback attempt — but in an interactive terminal, "short-circuit"
+  // means offering the same browser login-and-resume flow every other
+  // auth failure gets, not just printing a hint and exiting: the person is
+  // sitting right there. Retry exactly once with the fresh key; a repeat
+  // 401/403 (or non-interactive/CI) falls through to the plain AUTH_FAILED
+  // message, same as before this existed.
+  if (firstErr.httpStatus === 401 || firstErr.httpStatus === 403) {
+    if (process.stdin.isTTY && process.stdout.isTTY) {
+      try {
+        const { ensureLoggedIn } = await import('./onboarding.js');
+        console.log(chalk.yellow('\n  Your saved API key was rejected. Signing in again...'));
+        const fresh = await ensureLoggedIn({ apiKey: callOpts.apiKey, baseUrl: callOpts.baseUrl }, chalk);
+        callOpts.apiKey = fresh.apiKey;
+        return await attempt(buildBody());
+      } catch (retryErr) {
+        if (retryErr.isPaymentRequired) throw retryErr;
+        // Falls through to the same AUTH_FAILED message below, whether the
+        // re-login itself failed or the retried request 401/403'd again.
+      }
     }
+    throw new CapacityError(formatCliError('AUTH_FAILED', {}, chalk));
   }
 
-  // Tier-2 expansion: try budget-tier providers whenever tier-1 fails
-  if (effectiveTier !== '2' && allowTier2Fallback) {
-    console.log(chalk.dim('\n  Primary capacity unavailable — expanding search...\n'));
-    try {
-      return await attempt(buildBody('2'));
-    } catch (err2) {
-      throw buildCapacityError(err2, true);
-    }
-  }
+  const d = firstErr.errorData;
+
+  // No client-side "provider retry" here on purpose. The backend
+  // (reliability_engine.py / deployment_service.py's legacy provisioning
+  // loop) already tries every viable provider/offer for a request within
+  // the ONE deployment it creates before ever returning a failure -- a
+  // PROVISIONING_FAILED/PROVIDER_ADAPTER_ERROR response means that whole
+  // internal search already ran and a real, billable resource was very
+  // likely created and destroyed along the way (see deployment_service.
+  // _reliability_result_failure_reason and the legacy loop's own
+  // smoke-check-failure path, both of which only report these codes once
+  // a resource actually existed). A second /run or /serve call here would
+  // be an entirely new deployment repeating that same internal search from
+  // scratch -- duplicate billable exposure for a workload that was never a
+  // capacity problem in the first place. This CLI previously did retry
+  // once here with a `prefer_different_provider` flag the backend never
+  // actually reads (dead parameter, verified against the API source) --
+  // that retry never changed routing behavior, it just doubled exposure.
+  // A truthful WORKLOAD_START_FAILED/COMMAND_NOT_FOUND response (see
+  // serverToKey below) isn't even reachable here -- CapacityError is only
+  // for the capacity-flavored codes this function's own contract covers.
+
+  // The backend owns all provider and tier expansion for the deployment.
+  // Even NO_CAPACITY is terminal for this one submission: a second POST
+  // would create a second deployment id and split cleanup/audit ownership.
 
   throw buildCapacityError(firstErr, false);
 }

package/src/onboarding.js

@@ -115,17 +115,76 @@ async function ensureFunded(config, chalk) {
   console.log(chalk.green('\n  ✓ Payment confirmed\n'));
 }
 
-export async function ensureBadgrReady(config, chalk) {
+/**
+ * Just-in-time login only, no funding gate — for commands that manage or
+ * inspect an *existing* resource (stop it, read its logs, download its
+ * artifacts, reset its idle timer) rather than provisioning new spend.
+ * Critically, `badgr down` must never be blocked behind "add funds first" —
+ * a $0-balance user with a still-running deployment needs to be able to
+ * stop it without a funding detour. Same browser-login-and-resume flow as
+ * ensureBadgrReady, just without the ensureFunded step.
+ */
+export async function ensureLoggedInReady(config, chalk) {
   if (!process.stdin.isTTY || !process.stdout.isTTY) {
     // No human to click a browser link — fail fast with the existing message.
     requireApiKey(config);
     return config;
   }
+  if (!config.apiKey) {
+    return ensureLoggedIn(config, chalk);
+  }
+  return config;
+}
 
-  let cfg = config;
-  if (!cfg.apiKey) {
-    cfg = await ensureLoggedIn(cfg, chalk);
+/**
+ * Login + funding gate — for commands that provision new spend (run,
+ * serve, comfyui, launch/job, batch run, train, transcribe, embed, deploy,
+ * shell, sbatch, up). Reuses ensureLoggedInReady for the login half so
+ * there is exactly one login flow, not two.
+ */
+export async function ensureBadgrReady(config, chalk) {
+  if (!process.stdin.isTTY || !process.stdout.isTTY) {
+    // No human to click a browser link — fail fast with the existing
+    // message, same as ensureLoggedInReady, and skip ensureFunded too:
+    // there's no one to click the billing checkout link either.
+    requireApiKey(config);
+    return config;
   }
+  const cfg = await ensureLoggedInReady(config, chalk);
   await ensureFunded(cfg, chalk);
   return cfg;
 }
+
+/**
+ * Both ensureLoggedInReady and ensureBadgrReady only ever check whether a
+ * key is *configured* -- neither can tell a stored key is stale/expired/
+ * revoked without actually calling the API, so a command with a bad saved
+ * key sailed straight past both checks and only found out from the real
+ * request's own 401, which every command before this helper just printed
+ * ("Invalid API key ... run: badgr login") and exited. That's a dead end
+ * for the exact case ensureLoggedInReady/ensureBadgrReady exist to avoid:
+ * the person is sitting right there at an interactive terminal.
+ *
+ * withReauthRetry(config, chalk, fn) calls fn(config) once; on a 401/403
+ * in an interactive TTY, it opens the same browser login link
+ * ensureLoggedIn always has, waits for it, then retries fn exactly once
+ * with the fresh key. Any other error (including a repeat 401/403 after a
+ * successful re-login, or non-interactive/CI) is re-thrown unchanged for
+ * the caller's own existing error handling.
+ *
+ * Returns { config, result } -- callers should keep using the returned
+ * config (not their original variable) for anything they do afterward, so
+ * a refreshed key from a mid-command reauth is actually used for the rest
+ * of that same run instead of only being picked up by the next command.
+ */
+export async function withReauthRetry(config, chalk, fn) {
+  try {
+    return { config, result: await fn(config) };
+  } catch (err) {
+    if (err.httpStatus !== 401 && err.httpStatus !== 403) throw err;
+    if (!process.stdin.isTTY || !process.stdout.isTTY) throw err;
+    console.log(chalk.yellow('\n  Your saved API key was rejected. Signing in again...'));
+    const freshConfig = await ensureLoggedIn(config, chalk);
+    return { config: freshConfig, result: await fn(freshConfig) };
+  }
+}

package/src/progress.js

@@ -33,11 +33,14 @@ export function clearBlock(lineCount) {
 // `badgr serve` (deployment) and `badgr run` (job): elapsed time, a status
 // word, an *estimated* spend (never presented as confirmed while billing is
 // still live), and the exact commands to inspect logs or stop billing.
-export function renderLiveBlock(chalk, { stageLine, elapsedSec, statusWord, spend, id }) {
+export function renderLiveBlock(chalk, { stageLine, elapsedSec, statusWord, spend, id, maxCost }) {
+  const spendLine = maxCost
+    ? `        Estimated spend: ~$${spend.toFixed(2)} / $${maxCost.toFixed(2)}`
+    : `        Estimated spend: ~$${spend.toFixed(2)}`;
   return [
     chalk.dim(`${stageLine} ${elapsedSec}s elapsed`),
     chalk.dim(`        Status: ${statusWord}`),
-    chalk.dim(`        Estimated spend: ~$${spend.toFixed(2)}`),
+    chalk.dim(spendLine),
     chalk.dim(`        Logs: badgr logs ${id}`),
     chalk.dim(`        Stop billing: badgr down ${id}`),
   ];