@myapihq/cli 2.31.0 → 2.31.1

package/dist/commands/container-deploy-failure.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/commands/container-deploy-failure.test.js

@@ -0,0 +1,49 @@
+// A failed deploy has to say which half failed.
+//
+// One fixed sentence covered every failure: "Build/deploy failed — check
+// `myapi container logs <id>`". ImmoPilot read thirty lines of healthy nginx
+// after a ROLLOUT failure — the image had built, served two 200s to our own
+// startup probes, then taken a SIGTERM — and a second deploy of the same code
+// succeeded unchanged. The sentence sent them looking for a defect in code that
+// was fine.
+//
+// I hit the same message the day before, on a container the probe had already
+// deleted, so the logs it named did not exist either.
+//
+// The platform now returns error, error_stage and error_retryable, so the CLI
+// can stop guessing.
+import { describe, it, expect } from 'vitest';
+import { describeDeployFailure } from './container.js';
+const ID = 'c1';
+const base = { id: ID };
+describe('describeDeployFailure', () => {
+    it('leads with what the platform said, not our paraphrase', () => {
+        const out = describeDeployFailure({ ...base, error: 'Deployment failed after the image built.', error_stage: 'deploy' }, ID);
+        expect(out.split('\n')[0]).toBe('Deployment failed after the image built.');
+    });
+    it('on a rollout failure, says their application logs are the wrong place', () => {
+        // The whole point. "Check the logs" is what cost a customer a deploy.
+        const out = describeDeployFailure({ ...base, error_stage: 'deploy' }, ID);
+        expect(out).toMatch(/not the place to look/i);
+        expect(out).not.toContain(`myapi container logs ${ID}`);
+    });
+    it('on a build failure, sends them to the build logs', () => {
+        const out = describeDeployFailure({ ...base, error_stage: 'build' }, ID);
+        expect(out).toContain(`myapi container build-logs ${ID}`);
+    });
+    it('says so when the failure is ours and retrying is reasonable', () => {
+        const out = describeDeployFailure({ ...base, error_stage: 'deploy', error_retryable: true }, ID);
+        expect(out).toMatch(/retrying is reasonable/i);
+    });
+    it('does not invite a retry when the failure is theirs', () => {
+        // Telling someone to retry a broken build wastes four minutes per attempt.
+        const out = describeDeployFailure({ ...base, error_stage: 'build', error_retryable: false }, ID);
+        expect(out).not.toMatch(/retrying is reasonable/i);
+    });
+    it('offers both logs when the platform did not say which stage', () => {
+        // Older backends, and any future status that predates the field.
+        const out = describeDeployFailure(base, ID);
+        expect(out).toContain(`build-logs ${ID}`);
+        expect(out).toContain(`logs ${ID}`);
+    });
+});

package/dist/commands/container.d.ts

@@ -13,6 +13,7 @@ export declare function create(nameArg: string | undefined, flags: Flags): Promi
 export declare function list(flags: Flags): Promise<void>;
 export declare function get(id: string, flags: Flags): Promise<void>;
 export declare function healthCheck(id: string, flags: Flags): Promise<void>;
+export declare function describeDeployFailure(c: sdkContainer.Container, id: string): string;
 export declare function del(id: string, flags: Flags): Promise<void>;
 export declare function _checkProbePath(hc: string): string;
 export declare function _isTarball(p: string): boolean;

package/dist/commands/container.js

@@ -277,6 +277,39 @@ export async function healthCheck(id, flags) {
         ? `  The runtime now waits for ${value} to answer before sending traffic to a new revision.`
         : '  No startup probe: a new revision takes traffic as soon as the runtime reports it started.');
 }
+// What to say when a deploy fails, and where to send them.
+//
+// One fixed sentence used to cover every failure: "Build/deploy failed — check
+// `myapi container logs <id>`". A customer read thirty lines of healthy nginx
+// after a ROLLOUT failure — the image had built, served two 200s to our own
+// startup probes, then taken a SIGTERM — and a second deploy of the same code
+// succeeded unchanged. The message sent them to look for a defect in code that
+// was fine.
+//
+// The platform now says which stage failed and whether it is worth retrying,
+// so the CLI can stop guessing. `build` is their image; `deploy` is our rollout
+// of an image that built, which is the case where their application logs are
+// the wrong place to look.
+export function describeDeployFailure(c, id) {
+    const lines = [c.error?.trim() || 'The deploy failed.'];
+    if (c.error_stage === 'build') {
+        lines.push(`  Your image did not build: myapi container build-logs ${id}`);
+    }
+    else if (c.error_stage === 'deploy') {
+        // Said explicitly, because "check the logs" is what cost the customer a
+        // deploy: the image built and ran, so the application logs look healthy.
+        lines.push('  The image built — this failed while we rolled it out, so your');
+        lines.push('  application logs will look healthy and are not the place to look.');
+    }
+    else {
+        lines.push(`  Build logs: myapi container build-logs ${id}`);
+        lines.push(`  Runtime logs: myapi container logs ${id}`);
+    }
+    if (c.error_retryable) {
+        lines.push('  This one is ours and retrying is reasonable: myapi container deploy ' + id + ' --source <dir>');
+    }
+    return lines.join('\n');
+}
 export async function del(id, flags) {
     const config = requireConfig();
     const orgId = requireOrg(flags, config, 'myapi container delete <id> [--yes] [--org <id>]');
@@ -421,7 +454,7 @@ export async function deploy(id, image, flags) {
                 check: () => sdkContainer.getContainer(config.api_key, orgId, id),
                 isDone: (c) => c.status === 'active',
                 isFailed: (c) => c.status === 'build_error' || c.status === 'deploy_error',
-                failedMessage: 'Build/deploy failed — check `myapi container logs ' + id + '`.',
+                failedMessage: (c) => describeDeployFailure(c, id),
                 timeoutMs: 600_000,
                 intervalMs: 5_000,
             });

package/dist/utils.d.ts

@@ -20,8 +20,15 @@ export interface PollOptions<T> {
     intervalMs?: number;
     /** Message shown via error() on timeout. Defaults to a generic phrase. */
     timeoutMessage?: string;
-    /** Message shown via error() when isFailed returns true. */
-    failedMessage?: string;
+    /**
+     * Message shown via error() when isFailed returns true.
+     *
+     * A function when the useful message depends on WHY it failed. `container
+     * deploy` printed one fixed sentence for every failure, so a rollout problem
+     * and a broken build read identically — a customer spent a deploy reading
+     * healthy nginx logs because the sentence sent them there.
+     */
+    failedMessage?: string | ((state: T) => string);
 }
 /**
  * Generic spinner+poll helper. Used wherever the CLI kicks off a long-running

package/dist/utils.js

@@ -46,7 +46,10 @@ export async function pollJob(opts) {
         }
         if (opts.isFailed && opts.isFailed(state)) {
             clearLine();
-            error(opts.failedMessage ?? `${opts.label} failed`);
+            const msg = typeof opts.failedMessage === 'function'
+                ? opts.failedMessage(state)
+                : opts.failedMessage;
+            error(msg ?? `${opts.label} failed`);
         }
         spinnerWrite(`\r${opts.label} ${spinnerFrame(i++)}`);
         await sleep(intervalMs);

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@myapihq/cli",
   "license": "Apache-2.0",
-  "version": "2.31.0",
+  "version": "2.31.1",
   "description": "MyAPI command-line interface",
   "repository": {
     "type": "git",
@@ -47,7 +47,7 @@
     "lint:skills:strict": "node scripts/copy-skills.js && node scripts/lint-skills.js --strict"
   },
   "dependencies": {
-    "@myapihq/sdk": "^2.31.0"
+    "@myapihq/sdk": "^2.31.1"
   },
   "devDependencies": {
     "@types/node": "^25.6.0",