apps/web/app/(ee)/api/cron/workspaces/delete/route.ts (1)

109-109: Same QStash retry logic concern as other routes.

This route also uses verifyQstashSignature (line 19) but switches to handleCronErrorResponse. Please ensure the QStash retry mechanism is preserved in the new error handler.

apps/web/app/(ee)/api/cron/cleanup/expired-tokens/route.ts (1)

67-67: Same QStash retry logic concern as other routes.

This route uses verifyQstashSignature (line 19) but switches to handleCronErrorResponse. Ensure QStash retry logic is preserved.

apps/web/app/(ee)/api/cron/payouts/process/route.ts (1)

83-83: Same QStash retry logic concern as other routes.

This route uses verifyQstashSignature (line 31) but switches to handleCronErrorResponse. Ensure QStash retry logic is preserved.

apps/web/app/(ee)/api/cron/groups/remap-default-links/route.ts (1)

10-10: Cron utils integration is consistent with other routes

Using { handleCronErrorResponse, logAndRespond } here matches the pattern in other cron routes; same note as in import/csv about confirming whether the simpler cron error handler should influence QStash retry behavior.

Also applies to: 230-238

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/payouts/payout-stats.tsx (1)

140-141: Recommended refactor: Remove redundant " USD" suffix.

The currencyFormatter function already formats amounts with a currency symbol (e.g., $1,234.56). Appending " USD" results in redundant currency indication (e.g., $1,234.56 USD). Consider passing the currency option explicitly if needed, or removing the manual suffix.

As per the currencyFormatter documentation: the function uses Intl.NumberFormat with the currency style and defaults to USD when no explicit currency is provided.

Example refactor:

- {currencyFormatter(eligiblePendingPayouts?.amount ?? 0, {}) +
-   " USD"}
+ {currencyFormatter(eligiblePendingPayouts?.amount ?? 0, { currency: "USD" })}

You may defer this cleanup to a future PR if prioritizing other changes.

Also applies to: 198-198

apps/web/lib/auth/partner.ts (1)

171-174: Consider passing requestHeaders for QStash retry support.

The error handling update is correct and properly passes responseHeaders. However, since this function has access to req, consider also passing requestHeaders to enable QStash-aware retry logic when partner routes are called via QStash callbacks.

Apply this diff to add requestHeaders support:

       } catch (error) {
         return handleAndReturnErrorResponse({
           error,
           responseHeaders,
+          requestHeaders: req.headers,
         });
       }

apps/web/ui/modals/domain-auto-renewal-modal.tsx (1)

96-98: Minor formatting change unrelated to PR objective.

The text reflow here appears to be an unrelated formatting change. While it has no functional impact, it's worth noting that this cosmetic change doesn't align with the PR's retry mechanism objective.

apps/web/app/api/oauth/userinfo/route.ts (1)

73-77: Good improvement with consistent error naming.

The change correctly updates error handling to use the new object-based signature and improves consistency by renaming e to error. The CORS headers are properly passed as responseHeaders.

For completeness with the retry mechanism, consider also passing requestHeaders:

   } catch (error) {
     return handleAndReturnErrorResponse({
       error,
       responseHeaders: CORS_HEADERS,
+      requestHeaders: req.headers,
     });
   }

apps/web/ui/customers/customer-sales-table.tsx (1)

61-61: Cosmetic simplification - unrelated to PR objective.

The cell renderer has been simplified to a concise single-line form. While this improves readability, it's unrelated to the retry mechanism that is the focus of this PR.

apps/web/ui/customers/customer-partner-earnings-table.tsx (1)

36-36: Cosmetic simplification - unrelated to PR objective.

Both the "Sale Amount" and "Commission" cell renderers have been simplified to concise single-line forms. While this improves code consistency with customer-sales-table.tsx, these formatting changes are unrelated to the retry mechanism objective of this PR.

Also applies to: 41-41

apps/web/lib/api/queue-failed-request-for-retry.ts (2)

44-53: Consider wrapping QStash publish in try-catch.

If qstash.publishJSON fails (network issues, QStash unavailable), the error will propagate and could mask the original error or cause unexpected behavior in the caller. Since this is a best-effort retry mechanism, failures should be logged but not block the error response.

-  const response = await qstash.publishJSON({
-    url,
-    method,
-    body: await parseRequestBody(errorReq),
-    headers: {
-      ...Object.fromEntries(errorReq.headers.entries()),
-    },
-    delay: "10s",
-    retries: 5,
-  });
-
-  if (response.messageId) {
+  try {
+    const response = await qstash.publishJSON({
+      url,
+      method,
+      body: await parseRequestBody(errorReq),
+      headers: {
+        ...Object.fromEntries(errorReq.headers.entries()),
+      },
+      delay: "10s",
+      retries: 5,
+    });
+
+    if (response.messageId) {
+      console.log("Request queued for retry", {
+        method,
+        url,
+        messageId: response.messageId,
+      });
+
+      logger.info("request.retry.queued", {
+        url,
+        method,
+        messageId: response.messageId,
+      });
+
+      await logger.flush();
+    }
+  } catch (e) {
+    console.error("Failed to queue request for retry", { method, url, error: e });
+    logger.error("request.retry.queue_failed", { url, method, error: e });
+    await logger.flush();
+  }

---

48-50: Consider filtering sensitive headers before forwarding.

Forwarding all headers to QStash may inadvertently include sensitive information beyond the API key (e.g., cookies, internal tracing headers). Consider explicitly allowlisting headers that are necessary for retry.

+const ALLOWED_RETRY_HEADERS = [
+  "authorization",
+  "content-type",
+  "x-api-version",
+  // Add other necessary headers
+];
+
+function filterHeaders(headers: Headers): Record<string, string> {
+  const filtered: Record<string, string> = {};
+  for (const key of ALLOWED_RETRY_HEADERS) {
+    const value = headers.get(key);
+    if (value) filtered[key] = value;
+  }
+  return filtered;
+}

Then use headers: filterHeaders(errorReq.headers) instead of spreading all entries.

apps/web/lib/api/errors.ts (1)

59-63: Consider exporting ErrorHandlerOptions for caller type safety.

The interface is used in the public handleAndReturnErrorResponse signature but isn't exported. Callers may need to import this type to properly type their error handling code.

-interface ErrorHandlerOptions {
+export interface ErrorHandlerOptions {
   error: unknown;
   responseHeaders?: Headers;
   requestHeaders?: Headers;
 }

apps/web/app/(ee)/api/cron/import/csv/route.ts (1)

24-24: Confirm cron retry behavior with new error handler

This route now uses handleCronErrorResponse({ error }), which (per apps/web/app/(ee)/api/cron/utils.ts) just maps the error to { error, status } and doesn’t look at the request headers or set Upstash-NonRetryable-Error like handleAndReturnErrorResponse does. If this endpoint is invoked by QStash Cron, that may change how permanent vs transient errors are retried. Worth confirming whether cron failures should always be retried, or if you also want the non‑retryable header logic here.

Also applies to: 124-132

apps/web/app/api/links/metatags/route.ts (1)

34-45: Preserve CORS headers on error responses

Wrapping the error in { error } matches the new handleAndReturnErrorResponse signature. To keep CORS behavior consistent, consider:

} catch (error) {
  return handleAndReturnErrorResponse({
    error,
    responseHeaders: corsHeaders,
  });
}

so callers receive the same CORS headers on failures as on success.

apps/web/app/(ee)/api/cron/payouts/charge-succeeded/route.ts (1)

66-73: Standardized cron error response; consider tightening log typing

Switching the catch path to handleCronErrorResponse({ error }) keeps this route aligned with the new cron-wide error handling and retry semantics. To make the log call a bit safer, consider guarding error.message (as you already do in other routes) with an instanceof Error check or String(error).

apps/web/app/(ee)/api/cron/bounties/notify-partners/route.ts (1)

211-218: Error response now aligned with cron-wide behavior

Delegating to handleCronErrorResponse({ error }) after logging ensures a uniform JSON+status shape for cron failures, which is important for the new retry flow. As a minor improvement, you could mirror the instanceof Error guard used in other routes to avoid relying on error.message when error might not be an Error.

apps/web/app/(ee)/api/cron/import/tolt/route.ts (1)

47-49: Consistent cron error response; consider adding a log

Returning handleCronErrorResponse({ error }) standardizes the failure shape for this import job. If you want parity with other cron routes, consider logging the error (and perhaps payload.action) before returning, to make diagnosing failed Tolt imports easier.

apps/web/app/(ee)/api/cron/groups/sync-utm/route.ts (1)

145-151: Unified cron error response; optional hardening of log

The switch to handleCronErrorResponse({ error }) after logging ensures failures from this sync job surface through the standardized cron error pipeline. As a minor improvement, you may want to mirror the instanceof Error guard pattern from other routes so error.message access is always safe.

apps/web/app/(ee)/api/cron/import/short/route.ts (1)

61-68: Cron error response integration looks good; minor logging nit

The outer catch now logs and then returns handleCronErrorResponse({ error }), which is aligned with the new cron error model and retry behavior. If you want to be defensive, you can guard error.message in the log (and in the inner catch when building the DubApiError message) in case a non-Error slips through.

apps/web/app/(ee)/api/cron/payouts/balance-available/route.ts (1)

166-173: Standardized cron error handling; optional log robustness

Using handleCronErrorResponse({ error }) after logging ensures payout failures are reported through the same cron error pipeline that drives retries and monitoring. As a small hardening step, you might guard error.message in the log with an instanceof Error check, to be resilient to non-Error throws.

apps/web/app/(ee)/api/cron/fx-rates/route.ts (1)

5-5: Cron error handler integration is correct; consider minor type-safety tweak

The import path and handleCronErrorResponse({ error }) usage look correct and align this route with the new cron error handling.

If your TS config uses useUnknownInCatchVariables, you may eventually want to narrow error before interpolating error.message in the log (e.g., error instanceof Error ? error.message : String(error)), but that’s an optional clean-up and not introduced by this PR.

Also applies to: 52-52

apps/web/app/(ee)/api/cron/payouts/process/updates/route.ts (1)

9-9: Error routing wired correctly; log message could be clearer

The import path and handleCronErrorResponse({ error }) usage look correct and hook this updates worker into the shared cron error / retry handling.

Optionally, you might later tweak the log message (Error sending Stripe payout) to more clearly reference the payouts/process/updates job so logs are easier to grep by route, but that’s not blocking.

Also applies to: 180-180

apps/web/app/(ee)/api/cron/import/rebrandly/route.ts (1)

87-94: Cron error handling correctly delegates to handleCronErrorResponse (optional hardening)

Routing the outer catch through handleCronErrorResponse({ error }) standardizes cron responses and aligns with the cron-specific error pattern described in the learnings (no QStash callback detection or Upstash non‑retry headers in cron routes). Based on learnings, this is the intended behavior.

If your tsconfig uses useUnknownInCatchVariables, you might optionally normalize the error before accessing .message:

-  } catch (error) {
-    await log({
-      message: `Error importing Rebrandly links: ${error.message}`,
-      type: "cron",
-    });
-
-    return handleCronErrorResponse({ error });
-  }
+  } catch (error) {
+    const err = error instanceof Error ? error : new Error(String(error));
+
+    await log({
+      message: `Error importing Rebrandly links: ${err.message}`,
+      type: "cron",
+    });
+
+    return handleCronErrorResponse({ error: err });
+  }

Purely a safety/clarity tweak; behavior is otherwise sound.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: devkiran
Repo: dubinc/dub PR: 3213
File: apps/web/app/(ee)/api/cron/auto-approve-partner/route.ts:122-122
Timestamp: 2025-12-15T16:45:51.667Z
Learning: In the Dub codebase, cron endpoints under apps/web/app/(ee)/api/cron/ use handleCronErrorResponse for error handling, which intentionally does NOT detect QStash callbacks or set Upstash-NonRetryable-Error headers. This allows QStash to retry all cron job errors using its native retry mechanism. The selective retry logic (queueFailedRequestForRetry) is only used for specific user-facing API endpoints like /api/track/lead, /api/track/sale, and /api/links to retry only transient Prisma database errors.

Learnt from: devkiran
Repo: dubinc/dub PR: 3207
File: apps/web/lib/cron/with-cron.ts:27-56
Timestamp: 2025-12-09T12:54:41.818Z
Learning: In `apps/web/lib/cron/with-cron.ts`, the `withCron` wrapper extracts the request body once and provides it to handlers via the `rawBody` parameter. Handlers should use this `rawBody` string parameter (e.g., `JSON.parse(rawBody)`) rather than reading from the Request object via `req.json()` or `req.text()`.

Learnt from: devkiran
Repo: dubinc/dub PR: 3213
File: apps/web/app/(ee)/api/cron/auto-approve-partner/route.ts:122-122
Timestamp: 2025-12-15T16:45:51.667Z
Learning: In cron endpoints under apps/web/app/(ee)/api/cron, continue using handleCronErrorResponse for error handling. Do not detect QStash callbacks or set Upstash-NonRetryable-Error headers in these cron routes, so QStash can retry cron errors via its native retry mechanism. The existing queueFailedRequestForRetry logic should remain limited to specific user-facing API endpoints (e.g., /api/track/lead, /api/track/sale, /api/links) to retry only transient Prisma/database errors. This pattern should apply to all cron endpoints under the cron directory in this codebase.

Learnt from: devkiran
Repo: dubinc/dub PR: 2433
File: apps/web/ui/modals/add-payment-method-modal.tsx:60-62
Timestamp: 2025-05-29T09:49:19.604Z
Learning: The `/api/workspaces/${slug}/billing/payment-methods` POST endpoint in the billing API returns either an error (handled by response.ok check) or a response object containing a `url` property for successful requests.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2538
File: apps/web/ui/partners/overview/blocks/commissions-block.tsx:16-27
Timestamp: 2025-06-18T20:26:25.177Z
Learning: In the Dub codebase, components that use workspace data (workspaceId, defaultProgramId) are wrapped in `WorkspaceAuth` which ensures these values are always available, making non-null assertions safe. This is acknowledged as a common pattern in their codebase, though not ideal.