apps/web/app/(ee)/api/track/sale/client/route.ts (2)

41-46: Redundant runtime check if schema already enforces customerExternalId.

If trackSaleRequestSchema guarantees customerExternalId is present (or normalizes legacy fields into it), this manual check is unnecessary and duplicates validation logic. If not, consider moving this requirement into the schema for consistent error formatting.

---

75-80: Consider caching preflight for fewer OPTIONS hits.

Adding Access-Control-Max-Age can reduce preflight traffic for client integrations.

Apply this diff:

 export const OPTIONS = () => {
   return new Response(null, {
     status: 204,
     headers: COMMON_CORS_HEADERS,
   });
 };

Suggested update in apps/web/lib/api/cors.ts (outside this hunk):

export const COMMON_CORS_HEADERS = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "POST, OPTIONS",
  "Access-Control-Allow-Headers": "Content-Type, Authorization",
  "Access-Control-Max-Age": "600",
};

apps/web/tests/utils/env.ts (1)

14-15: Optional: Avoid exporting a precomputed env to reduce import-time side effects.

Export a getEnv() function returning integrationTestEnv.parse(process.env) so tests can control when validation occurs.

apps/web/tests/utils/helpers.ts (1)

31-33: Hoist sale amounts into a constant to avoid reallocations and improve typing.

Minor nit: reuse a single array and leverage as const for tighter types.

Apply this diff:

-export const randomSaleAmount = () => {
-  return randomValue([400, 900, 1900]);
-};
+const SALE_AMOUNTS = [400, 900, 1900] as const;
+export const randomSaleAmount = () => randomValue(SALE_AMOUNTS);

apps/web/tests/tracks/track-sale.test.ts (1)

133-135: Reduce flakiness by polling instead of fixed sleep.

Replace fixed 2s delay with a small polling loop (e.g., up to 10s, 200ms interval) for eventual consistency when verifying commissions.

Here’s a lightweight pattern:

async function waitFor<T>(fn: () => Promise<T>, predicate: (x: T) => boolean, timeoutMs = 10000, intervalMs = 200) {
  const start = Date.now();
  // eslint-disable-next-line no-constant-condition
  while (true) {
    const val = await fn();
    if (predicate(val)) return val;
    if (Date.now() - start > timeoutMs) throw new Error("Timeout waiting for condition");
    await new Promise((r) => setTimeout(r, intervalMs));
  }
}

// Usage inside the test: await waitFor(() => http.get({...}), res => res.status === 200 && res.data.length === 1)

apps/web/lib/auth/publishable-key.ts (2)

76-81: Expose rate-limit headers to browsers.

Without Access-Control-Expose-Headers, client JS can’t read X-RateLimit-* and Retry-After. Consider adding this to COMMON_CORS_HEADERS.

Outside this file (apps/web/lib/api/cors.ts):

export const COMMON_CORS_HEADERS = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "POST, OPTIONS",
  "Access-Control-Allow-Headers": "Content-Type, Authorization",
  "Access-Control-Expose-Headers": "Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset",
  "Access-Control-Max-Age": "600",
};

---

103-105: Optional: propagate rate-limit headers on successful responses for parity.

Right now only 429/error paths include rate-limit metadata. If you want clients to budget calls proactively, consider attaching headers to the handler’s success response as well (e.g., by cloning and augmenting the Response returned by handler).

apps/web/tests/tracks/track-lead-client.test.ts (2)

26-26: Nit: test title mentions the wrong prior endpoint.

The title says “from a prior /track/lead/client request” but the clickId comes from /track/click. The diff above fixes the wording.

---

1-2: Optional: reuse IntegrationHarness.http for uniform client behavior/logging.

You could replace fetch with h.http.post and pass a custom Authorization header (publishable key) to keep request plumbing, error handling, and diagnostics consistent across tests. Not required, just consistency sugar.

apps/web/tests/tracks/track-sale-client-test.ts (1)

21-29: Verify CORS header propagation in the sale-client test

The sale-client endpoint returns the standard CORS headers (via COMMON_CORS_HEADERS), but does not include any rate-limit headers on success. You can optionally assert that the critical CORS headers are correctly propagated:

• File: apps/web/tests/tracks/track-sale-client-test.ts
Around lines 21–29, after you obtain response, add:

// Assert CORS headers are present and correct
expect(response.headers.has("access-control-allow-origin")).toBe(true);
expect(response.headers.get("access-control-allow-origin")).toBe("*");

// (Optional) also check additional CORS headers if desired
expect(response.headers.get("access-control-allow-methods")).toContain("POST");
expect(response.headers.get("access-control-allow-headers")).toContain("Content-Type");

Since this route isn’t rate-limited in the happy-path, you can skip any X-RateLimit-* or Retry-After checks here.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: steven-tey
PR: dubinc/dub#2737
File: apps/web/lib/api/cors.ts:1-5
Timestamp: 2025-08-21T03:03:39.879Z
Learning: Dub publishable keys are sent via Authorization header using Bearer token format, not via custom X-Dub-Publishable-Key header. The publishable key middleware extracts keys using req.headers.get("Authorization")?.replace("Bearer ", "") and validates they start with "dub_pk_".

Learnt from: steven-tey
PR: dubinc/dub#2737
File: apps/web/lib/api/cors.ts:1-5
Timestamp: 2025-08-21T03:03:39.879Z
Learning: Dub publishable keys are sent via Authorization header using Bearer token format, not via custom X-Dub-Publishable-Key header. The publishable key middleware extracts keys using req.headers.get("authorization")?.replace("Bearer ", "").

apps/web/app/(ee)/api/track/sale/client/route.ts (1)

30-39: Good immutability tweak; const destructuring is appropriate here.

No functional change and prevents accidental reassignment of parsed fields. Looks good.

apps/web/tests/utils/helpers.ts (1)

2-2: Nice: consolidates randomness utilities in a shared helper.

Importing randomValue here reduces duplication across tests.

apps/web/tests/tracks/track-sale.test.ts (1)

2-2: LGTM: centralizes randomSaleAmount import.

Removes the local helper and reuses the shared one; keeps tests DRY.

apps/web/tests/tracks/track-lead-client.test.ts (1)

43-55: Your script will locate the cors.ts definition and show exactly which CORS headers are included, so we can tailor the test assertions to the real header names. Let me know the output, and I’ll finalize the review comment with precise examples.

apps/web/tests/utils/integration.ts (1)

55-59: LGTM: returning env from init improves ergonomics for client-route tests.

This aligns the harness with publishable-key flows that need env.E2E_BASE_URL and env.E2E_PUBLISHABLE_KEY.

.github/workflows/e2e.yaml (4)

12-13: Bump actions/checkout from v2 to v4 for security and performance.

v4 includes security hardening and bugfixes. No behavior change expected for basic checkout.

Apply:

-        uses: actions/checkout@v2
+        uses: actions/checkout@v4

---

1-6: Set least-privilege GITHUB_TOKEN permissions at the workflow root.

Explicit permissions reduce blast radius and satisfy org security policies.

 name: Public API Tests

 on:
   deployment_status:
 
+permissions:
+  contents: read
+  # tighten further if not needed:
+  actions: read
+  checks: read
+  deployments: read
+  statuses: read
+
 jobs:

---

33-43: Optional: add a guard to fail fast if any required E2E secrets are missing.

Prechecking avoids confusing test failures when env vars are unset.

       - name: Run tests
         working-directory: apps/web
         env:
           E2E_BASE_URL: ${{ github.event.deployment_status.environment_url }}
           E2E_TOKEN: ${{ secrets.E2E_TOKEN }}
           E2E_TOKEN_OLD: ${{ secrets.E2E_TOKEN_OLD }}
           E2E_PUBLISHABLE_KEY: ${{ secrets.E2E_PUBLISHABLE_KEY }}
           QSTASH_TOKEN: ${{ secrets.QSTASH_TOKEN }}
           QSTASH_CURRENT_SIGNING_KEY: ${{ secrets.QSTASH_CURRENT_SIGNING_KEY }}
           NEXT_PUBLIC_NGROK_URL: ${{ github.event.deployment_status.environment_url }}
-        run: pnpm test
+        run: |
+          set -euo pipefail
+          for v in E2E_BASE_URL E2E_TOKEN E2E_PUBLISHABLE_KEY; do
+            if [ -z "${!v:-}" ]; then echo "Missing required env: $v"; exit 1; fi
+          done
+          pnpm test

---

3-10: Optional: add concurrency to prevent duplicate runs for the same ref/environment.

Prevents rate-limit flakiness when multiple deployments fire in quick succession.

 on:
   deployment_status:
 
+concurrency:
+  group: public-api-tests-${{ github.event.deployment_status.environment }}-${{ github.sha }}
+  cancel-in-progress: true
+
 jobs:

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

.github/workflows/e2e.yaml (1)

39-39: Confirm test wiring is correct; manually verify secret exists

The workflow now correctly passes E2E_PUBLISHABLE_KEY into the test environment, and the tests consume it as expected:

• apps/web/tests/utils/env.ts defines and parses E2E_PUBLISHABLE_KEY via integrationTestEnv.parse(process.env) (line 7).
• apps/web/tests/tracks/track-sale-client-test.ts references it in the Authorization header (line 26).
• apps/web/tests/tracks/track-lead-client.test.ts likewise uses env.E2E_PUBLISHABLE_KEY (line 31).

Since the CI environment in this sandbox couldn’t confirm the presence of the secret in GitHub Actions, please manually ensure that E2E_PUBLISHABLE_KEY is configured at the repository or organization level under Settings → Secrets.

apps/web/tests/tracks/track-sale-client.test.ts (5)

36-38: Parse JSON after asserting HTTP status; also assert ok and content-type

If the endpoint ever returns a non-JSON error (or an empty body), calling response.json() first will throw and hide a clearer assertion. Check ok/status and content-type before parsing.

-    const saleResponse = await response.json();
-
-    expect(response.status).toEqual(200);
+    expect(response.ok).toBe(true);
+    expect(response.status).toBe(200);
+    expect(response.headers.get("content-type")).toContain("application/json");
+    const saleResponse = await response.json();

---

39-60: Use toMatchObject to make the assertion resilient to additive response fields

toStrictEqual will fail if the API adds non-breaking fields. toMatchObject keeps the test stable while still verifying the contract.

-    expect(saleResponse).toStrictEqual({
+    expect(saleResponse).toMatchObject({
       eventName: "Subscription",
       customer: {
         id: E2E_CUSTOMER_ID,
         name: expect.any(String),
         email: expect.any(String),
         avatar: expect.any(String),
         externalId: E2E_CUSTOMER_EXTERNAL_ID,
       },
       sale: {
         amount: sale.amount,
         currency: sale.currency,
         paymentProcessor: sale.paymentProcessor,
         invoiceId: sale.invoiceId,
         metadata: null,
       },
       amount: sale.amount,
       currency: sale.currency,
       paymentProcessor: sale.paymentProcessor,
       metadata: null,
       invoiceId: sale.invoiceId,
     });

---

38-38: Exercise new publishable-key headers: assert rate-limit and CORS header presence

PR objectives mention propagating CORS and rate-limit headers. Add assertions so regressions are caught. Header names may differ; adjust accordingly.

     expect(response.status).toBe(200);
+    // Rate limit headers
+    expect(response.headers.has("x-ratelimit-limit")).toBe(true);
+    expect(response.headers.has("x-ratelimit-remaining")).toBe(true);
+    expect(response.headers.has("x-ratelimit-reset")).toBe(true);
+    // CORS header
+    expect(response.headers.has("access-control-allow-origin")).toBe(true);

If your implementation uses different header keys (e.g., X-RateLimit-* casing or Retry-After), swap them in these checks.

---

8-8: Prefer consistent import style for test utilities

You’re using path aliases for helpers/resources but a relative import for IntegrationHarness. Standardize to the alias for consistency.

-import { IntegrationHarness } from "../utils/integration";
+import { IntegrationHarness } from "tests/utils/integration";

---

22-34: Optional: Add a negative-path test for auth and payload validation

Consider adding cases for missing/invalid publishable key and invalid payload (e.g., missing invoiceId) to cover error responses and rate-limit headers on errors as per PR goals.

I can draft a companion test (e.g., test("rejects without publishable key", ...) and test("rejects with invalid body", ...)) if you want to include them in this PR.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

apps/web/tests/tracks/track-sale-client.test.ts (1)

14-21: Good use of deterministic randomness and stable payload shape

Random amount sampling and unique invoiceId help avoid data collisions across runs, while keeping assertions straightforward.