@prodcycle/prodcycle 0.6.4 → 0.6.6

package/dist/api-client.js

@@ -47,10 +47,25 @@ const MAX_RETRY_AFTER_SECONDS = envInt('PC_MAX_RETRY_AFTER_SECONDS', 300);
 /**
  * Per-request fetch timeout. Without this a stalled connection would tie
  * up the CLI indefinitely, bypassing both the retry cap and the async-poll
- * deadline. Default is 2 minutes — long enough for the largest non-async
- * sync `/validate` call, short enough that a hung TCP socket gets aborted.
+ * deadline.
+ *
+ * Default is 5 minutes — chosen so the chunked-session `/chunks` upload
+ * path has enough headroom under server-side load. The bottleneck on
+ * busy servers is the per-chunk transaction (policy eval + per-finding
+ * unique-index check on `(scan_id, fingerprint)`), which can take tens
+ * of seconds on big chunks. Sync `/validate` scans normally finish in
+ * seconds, so a longer default doesn't hurt them — it only matters
+ * when a single request stalls. CI runs that want tighter feedback can
+ * shrink via `PC_REQUEST_TIMEOUT_MS`.
+ *
+ * Pre-fix this was 120 s and a megarepo chunked scan (infisical-
+ * infisical, ~11.5 k files, 2026-05-13 GA-validation sweep) burned
+ * through the full retry budget (4 × 120 s per stuck chunk) before
+ * giving up with `Failed to connect to ProdCycle API: The operation
+ * was aborted due to timeout`. The body-read retry path from #30 was
+ * firing correctly — it just wasn't enough budget.
  */
-const REQUEST_TIMEOUT_MS = envInt('PC_REQUEST_TIMEOUT_MS', 120_000);
+const REQUEST_TIMEOUT_MS = envInt('PC_REQUEST_TIMEOUT_MS', 300_000);
 /**
  * Conservative client-side chunk sizing for the chunked-session flow. The
  * /chunks endpoint accepts up to 50 MB / 2000 files per request, but most
@@ -384,7 +399,20 @@ class ComplianceApiClient {
             const retryAfterSeconds = parseRetryAfter(response.headers.get('retry-after'));
             const errorBody = parsed ?? null;
             const errorMessage = errorBody?.error?.message ?? `API request failed with status ${response.status}`;
-            const isRetryable = response.status === 429 || response.status === 503;
+            // 429 (rate limit) and 503 (service unavailable) honor Retry-After.
+            // 502 (bad gateway) and 504 (gateway timeout) are transient ALB-layer
+            // failures — the backend wasn't reached / didn't respond in time, so
+            // the request was not processed and a fresh attempt has a clean
+            // chance of succeeding. Concrete case: openbao-openbao got an
+            // instantaneous 502 during the 2026-05-13 GA-validation sweep and
+            // the CLI bailed without retry, even though the very next repo
+            // scanned cleanly. 500 is deliberately NOT retried — that's an
+            // application-level error and retrying could double-process or
+            // just deterministically refail.
+            const isRetryable = response.status === 429 ||
+                response.status === 502 ||
+                response.status === 503 ||
+                response.status === 504;
             if (isRetryable && attempt < MAX_RETRY_ATTEMPTS - 1) {
                 const delayMs = retryAfterSeconds != null ? retryAfterSeconds * 1000 : retryBackoffMs(attempt);
                 const cappedDelayMs = Math.min(delayMs, MAX_RETRY_AFTER_SECONDS * 1000);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@prodcycle/prodcycle",
-  "version": "0.6.4",
+  "version": "0.6.6",
   "description": "Multi-framework policy-as-code compliance scanner for infrastructure and application code.",
   "homepage": "https://docs.prodcycle.com",
   "repository": {