mobbdev 1.4.65 → 1.4.67

package/dist/args/commands/upload_ai_blame.mjs

@@ -1485,6 +1485,11 @@ var init_analysis = __esm({
       createdOn: z3.string(),
       state: z3.enum(Fix_Report_State_Enum),
       isFixEnabled: z3.boolean().nullish(),
+      // When this report's fixes expire(d). Nullish because the column is, and
+      // because the issue screen reads it only to date the "fixes expired"
+      // messaging — a missing date degrades to the undated wording rather than
+      // failing the parse (MOBB-3769).
+      expirationOn: z3.string().nullish(),
       repo: z3.object({
         name: z3.string().nullable(),
         originalUrl: z3.string(),
@@ -1579,7 +1584,10 @@ var init_issue = __esm({
           })
         }).transform(async ({ sourceCodeFile }) => {
           const { url } = sourceCodeFile.signedFile;
-          const sourceCodeRes = await fetch(url);
+          const sourceCodeRes = await fetch(url).catch(() => null);
+          if (!sourceCodeRes?.ok) {
+            return null;
+          }
           if (Number(sourceCodeRes.headers.get("Content-Length")) > MAX_SOURCE_CODE_FILE_SIZE_IN_BYTES) {
             return null;
           }
@@ -1590,16 +1598,40 @@ var init_issue = __esm({
         })
       ).transform((nodes) => nodes.filter((node) => node !== null)),
       fix: FixPartsForFixScreenZ.nullish(),
+      // Null when the diff cannot actually be read, not merely when the row is
+      // absent. The `vulnerability_report_issue_node_diff_file_id` column outlives
+      // the object it points at — only code-node rows are GC'd — and `getFile`
+      // signs a URL without checking existence, so a fixes-expired report hands
+      // back a perfectly valid URL for an object the lifecycle already swept.
+      //
+      // Treating the row as proof of the object put an empty box under "The issue
+      // was reported in the following locations:", because the renderer took the
+      // diff branch and had nothing to draw. Collapsing to null falls back to the
+      // locations list, which is the honest thing to show. Same rule as the
+      // snippet reader: an id is not evidence a file exists.
       vulnerabilityReportIssueNodeDiffFile: z4.object({
         signedFile: z4.object({
           url: z4.string()
-        }).transform(async ({ url }) => {
-          const codeDiff = await fetch(url).then((res) => res.text());
-          return { codeDiff };
         })
-      }).nullish(),
+      }).nullish().transform(async (nodeDiffFile) => {
+        if (!nodeDiffFile) {
+          return nodeDiffFile;
+        }
+        const response = await fetch(nodeDiffFile.signedFile.url).catch(
+          () => null
+        );
+        if (!response?.ok) {
+          return null;
+        }
+        return { signedFile: { codeDiff: await response.text() } };
+      }),
       sharedState: VulnerabilityReportIssueSharedStateZ,
-      unfixableId: z4.guid().nullish()
+      unfixableId: z4.guid().nullish(),
+      // The DB link to the fix, which outlives the fix's S3 artifacts. Non-null
+      // means "this issue had a fix" even when `fix` above is absent because the
+      // report's fixes expired, and that distinction is what keeps such an issue
+      // from being rendered as if it were never fixable (MOBB-3769).
+      fixId: z4.guid().nullish()
     });
     FalsePositivePartsZ = z4.object({
       extraContext: z4.array(z4.object({ key: z4.string(), value: z4.string() })),
@@ -1619,7 +1651,13 @@ var init_issue = __esm({
       z4.object({
         category: z4.literal("FalsePositive" /* FalsePositive */),
         fpId: z4.guid(),
-        getFalsePositive: FalsePositivePartsZ
+        // Nullish, like getUnfixable on GeneralIssueZ, because the explanation can
+        // genuinely be absent: the analyzer's pickle dies with the report's fixes,
+        // and issues processed before the persistent store existed (MOBB-3768)
+        // have nothing to fall back to. This used to be required, so the
+        // resolver's error member failed the parse and took down the entire issue
+        // screen instead of rendering one "explanation unavailable" accordion.
+        getFalsePositive: FalsePositivePartsZ.nullish()
       }).shape
     );
     GeneralIssueZ = BaseIssuePartsZ.extend(
@@ -2002,6 +2040,10 @@ var init_types = __esm({
       severityText: z7.enum(Vulnerability_Severity_Enum),
       vulnerabilityReportIssues: z7.array(
         z7.object({
+          // The row's reroute target once fixes expire: a fix's own page cannot
+          // render without its S3 patch, so the fixable bucket points the row
+          // at this issue instead (MOBB-3769).
+          id: z7.guid(),
           issueType: z7.string(),
           issueLanguage: z7.string(),
           sharedState: IssueSharedStateZ2
@@ -2146,7 +2188,11 @@ var init_types = __esm({
           email: z7.string()
         }).nullable(),
         state: z7.enum(Fix_Report_State_Enum),
-        expirationOn: z7.string()
+        expirationOn: z7.string(),
+        // Whether this org has fixes at all. Scan-only reports hit the same
+        // expiry date as every other report, so the list needs this to avoid
+        // badging them for fixes they never had (MOBB-3769).
+        isFixEnabled: z7.boolean()
       })
     });
     GetProjectsQueryZ = z7.object({

package/dist/index.mjs

@@ -1590,6 +1590,11 @@ var init_analysis = __esm({
       createdOn: z4.string(),
       state: z4.enum(Fix_Report_State_Enum),
       isFixEnabled: z4.boolean().nullish(),
+      // When this report's fixes expire(d). Nullish because the column is, and
+      // because the issue screen reads it only to date the "fixes expired"
+      // messaging — a missing date degrades to the undated wording rather than
+      // failing the parse (MOBB-3769).
+      expirationOn: z4.string().nullish(),
       repo: z4.object({
         name: z4.string().nullable(),
         originalUrl: z4.string(),
@@ -1684,7 +1689,10 @@ var init_issue = __esm({
           })
         }).transform(async ({ sourceCodeFile }) => {
           const { url } = sourceCodeFile.signedFile;
-          const sourceCodeRes = await fetch(url);
+          const sourceCodeRes = await fetch(url).catch(() => null);
+          if (!sourceCodeRes?.ok) {
+            return null;
+          }
           if (Number(sourceCodeRes.headers.get("Content-Length")) > MAX_SOURCE_CODE_FILE_SIZE_IN_BYTES) {
             return null;
           }
@@ -1695,16 +1703,40 @@ var init_issue = __esm({
         })
       ).transform((nodes) => nodes.filter((node) => node !== null)),
       fix: FixPartsForFixScreenZ.nullish(),
+      // Null when the diff cannot actually be read, not merely when the row is
+      // absent. The `vulnerability_report_issue_node_diff_file_id` column outlives
+      // the object it points at — only code-node rows are GC'd — and `getFile`
+      // signs a URL without checking existence, so a fixes-expired report hands
+      // back a perfectly valid URL for an object the lifecycle already swept.
+      //
+      // Treating the row as proof of the object put an empty box under "The issue
+      // was reported in the following locations:", because the renderer took the
+      // diff branch and had nothing to draw. Collapsing to null falls back to the
+      // locations list, which is the honest thing to show. Same rule as the
+      // snippet reader: an id is not evidence a file exists.
       vulnerabilityReportIssueNodeDiffFile: z5.object({
         signedFile: z5.object({
           url: z5.string()
-        }).transform(async ({ url }) => {
-          const codeDiff = await fetch(url).then((res) => res.text());
-          return { codeDiff };
         })
-      }).nullish(),
+      }).nullish().transform(async (nodeDiffFile) => {
+        if (!nodeDiffFile) {
+          return nodeDiffFile;
+        }
+        const response = await fetch(nodeDiffFile.signedFile.url).catch(
+          () => null
+        );
+        if (!response?.ok) {
+          return null;
+        }
+        return { signedFile: { codeDiff: await response.text() } };
+      }),
       sharedState: VulnerabilityReportIssueSharedStateZ,
-      unfixableId: z5.guid().nullish()
+      unfixableId: z5.guid().nullish(),
+      // The DB link to the fix, which outlives the fix's S3 artifacts. Non-null
+      // means "this issue had a fix" even when `fix` above is absent because the
+      // report's fixes expired, and that distinction is what keeps such an issue
+      // from being rendered as if it were never fixable (MOBB-3769).
+      fixId: z5.guid().nullish()
     });
     FalsePositivePartsZ = z5.object({
       extraContext: z5.array(z5.object({ key: z5.string(), value: z5.string() })),
@@ -1724,7 +1756,13 @@ var init_issue = __esm({
       z5.object({
         category: z5.literal("FalsePositive" /* FalsePositive */),
         fpId: z5.guid(),
-        getFalsePositive: FalsePositivePartsZ
+        // Nullish, like getUnfixable on GeneralIssueZ, because the explanation can
+        // genuinely be absent: the analyzer's pickle dies with the report's fixes,
+        // and issues processed before the persistent store existed (MOBB-3768)
+        // have nothing to fall back to. This used to be required, so the
+        // resolver's error member failed the parse and took down the entire issue
+        // screen instead of rendering one "explanation unavailable" accordion.
+        getFalsePositive: FalsePositivePartsZ.nullish()
       }).shape
     );
     GeneralIssueZ = BaseIssuePartsZ.extend(
@@ -2049,6 +2087,10 @@ var init_types = __esm({
       severityText: z7.enum(Vulnerability_Severity_Enum),
       vulnerabilityReportIssues: z7.array(
         z7.object({
+          // The row's reroute target once fixes expire: a fix's own page cannot
+          // render without its S3 patch, so the fixable bucket points the row
+          // at this issue instead (MOBB-3769).
+          id: z7.guid(),
           issueType: z7.string(),
           issueLanguage: z7.string(),
           sharedState: IssueSharedStateZ2
@@ -2193,7 +2235,11 @@ var init_types = __esm({
           email: z7.string()
         }).nullable(),
         state: z7.enum(Fix_Report_State_Enum),
-        expirationOn: z7.string()
+        expirationOn: z7.string(),
+        // Whether this org has fixes at all. Scan-only reports hit the same
+        // expiry date as every other report, so the list needs this to avoid
+        // badging them for fixes they never had (MOBB-3769).
+        isFixEnabled: z7.boolean()
       })
     });
     GetProjectsQueryZ = z7.object({
@@ -18568,7 +18614,7 @@ function createLogger(config2) {
 
 // src/features/claude_code/hook_logger.ts
 var DD_RUM_TOKEN = true ? "pubf59c0182545bfb4c299175119f1abf9b" : "";
-var CLI_VERSION = true ? "1.4.65" : "unknown";
+var CLI_VERSION = true ? "1.4.67" : "unknown";
 var NAMESPACE = "mobbdev-claude-code-hook-logs";
 var claudeCodeVersion;
 function buildDdTags() {
@@ -23747,7 +23793,7 @@ All tools require authentication via the Mobb API. The tools will handle authent
 
 Common scenarios:
 - **No fixes found**: Repository has no vulnerabilities or they're not fixable
-- **Report expired**: Previous scan is too old, need to rescan
+- **Fixes expired**: The previous scan's fixes have aged out \u2014 rescan to get new ones (the findings themselves stay viewable in the web app)
 - **No report found**: No previous scan exists, run scan_and_fix_vulnerabilities
 - **Authentication required**: User needs to authenticate with Mobb
 
@@ -24257,18 +24303,19 @@ var expiredReportPrompt = ({
   lastReportDate
 }) => `\u{1F50D} **MOBB SECURITY SCAN STATUS**
 
-## Out-of-Date Vulnerability Report
+## Fixes Have Expired
 
-Your most recent vulnerability report for this repository **expired on ${lastReportDate}** and is no longer available for fetching automated fixes.
+The fixes from your most recent vulnerability report for this repository **expired on ${lastReportDate}**, so there are no automated fixes left to fetch.
 
 ### \u{1F4CB} Why Did This Happen?
-- Reports are automatically purged after a retention period for security and storage optimization.
-- No new scans have been run since the last report expired.
+- Fixes are kept for a limited window after an analysis (extendable), and this one has passed.
+- The findings themselves have not gone anywhere: the report is still viewable in the Mobb web app, with every issue, location and severity intact.
+- No new scans have been run since those fixes expired.
 
 ### \u{1F3AF} Recommended Actions
-1. **Run a fresh security scan** to generate an up-to-date vulnerability report.
+1. **Run a fresh security scan** to generate new fixes for the current code.
    - Use the \`${MCP_TOOL_SCAN_AND_FIX_VULNERABILITIES}\` tool.
-2. **Verify repository access** if scans fail to run or the repository has moved.
+2. **Open the existing report in the web app** if you need the findings themselves \u2014 for an audit, a compliance review, or to see what was reported.
 3. **Review your CI/CD pipeline** to ensure regular scans are triggered.
 
 For more help:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mobbdev",
-  "version": "1.4.65",
+  "version": "1.4.67",
   "description": "Automated secure code remediation tool",
   "repository": "git+https://github.com/mobb-dev/bugsy.git",
   "main": "dist/index.mjs",