Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CR
PR: stack-auth/stack-auth#0
File: AGENTS.md:0-0
Timestamp: 2025-10-20T22:25:40.427Z
Learning: Applies to apps/backend/src/app/api/latest/**/route.ts : In backend API routes, use the custom route handler system to ensure consistent API responses

apps/dashboard/src/components/data-table/transaction-table.tsx (1)

131-139: USD-only handling remains unresolved.

This issue was already flagged in a previous review. The function still only displays USD amounts and shows '—' for all other currencies, which blanks the amount column for non-USD tenants. Please refer to the previous review comment for the proposed solution.

apps/dashboard/src/components/data-table/transaction-table.tsx (2)

51-58: Consider simplifying the redundant check.

The condition at line 56 returns 'other' when a productGrant exists without subscription or purchase IDs, but line 57 also returns 'other' as the default. Since both paths lead to the same result, line 56 can be removed.

Apply this diff:

 function deriveSourceType(transaction: Transaction): SourceType {
   if (transaction.entries.some(isItemQuantityChangeEntry)) return 'item_quantity_change';
   const productGrant = transaction.entries.find(isProductGrantEntry);
   if (productGrant?.subscription_id) return 'subscription';
   if (productGrant?.one_time_purchase_id) return 'one_time';
-  if (productGrant) return 'other';
   return 'other';
 }

---

86-89: Improve type safety in the default fallback.

The as any cast suppresses type checking. Since transactionType is typed as TransactionType | null, the default case should only handle null. Consider using a type-safe fallback.

Apply this diff:

     default: {
-      return { label: (transactionType as any) ?? '—', Icon: CircleHelp };
+      return { label: transactionType ?? 'Unknown', Icon: CircleHelp };
     }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/dashboard/src/components/data-table/transaction-table.tsx (2)

131-139: Fix amount display for non-USD charges.

This issue was flagged in a previous review and remains unresolved. pickChargedAmountDisplay only returns USD amounts; all other currencies render as '—', which blanks the amount column for non-USD tenants.

---

192-218: Fix critical type mismatch in transaction filtering logic.

This issue was flagged in a previous review and remains unresolved. The column returns SourceType values but the toolbar populates the filter dropdown with TransactionType values from TRANSACTION_TYPES. These value sets don't overlap, so filtering will never match and always return empty results.

apps/backend/src/app/api/latest/internal/payments/transactions/transaction-builder.ts (1)

125-146: Net amount is forced to USD "0" for non‑USD charges.

This issue was flagged in a previous review and remains unresolved. If a purchase is denominated solely in a non-USD currency (e.g., EUR), this code emits net_amount: { USD: "0" }, causing downstream reporting to falsely record zero revenue.

This is compounded by the schema constraint in packages/stack-shared/src/interface/crud/transactions.ts (lines 90-92) that only allows USD in net_amount.

apps/backend/src/app/api/latest/internal/payments/transactions/transaction-builder.ts (1)

263-291: Unused parameter in buildItemQuantityChangeTransaction.

The tenancy parameter is accepted but never used in the function body. Consider removing it if it's not needed, or add a comment explaining why it's reserved for future use.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/backend/src/app/api/latest/internal/payments/transactions/transaction-builder.ts (1)

124-145: Net amount is forced to USD "0" for non‑USD charges.

This issue was already identified in a previous review. When a purchase is denominated solely in EUR or another non-USD currency, this code still emits net_amount: { USD: "0" }, falsely recording zero revenue. The net_amount should reflect the actual charged currencies instead of fabricating zero USD values.

apps/backend/src/app/api/latest/internal/payments/transactions/transaction-builder.ts (2)

30-52: Consider validating the fallback structure.

The as ProductSnapshot cast on line 41 bypasses type checking. While the structure appears complete, if ProductSnapshot evolves, this could lead to runtime type mismatches.

Consider using a schema validator or ensuring all fields match the expected type explicitly:

   return {
     display_name: options.displayName,
     customer_type: options.customerType,
     prices: {},
     stackable: false,
     server_only: false,
     included_items: {},
+    client_metadata: null,
+    client_read_only_metadata: null,
+    server_metadata: null,
-  } as ProductSnapshot;
+  };

---

172-260: Consider extracting shared logic from subscription and one-time purchase builders.

buildSubscriptionTransaction and buildOneTimePurchaseTransaction share nearly identical logic (~45 lines of duplication), differing only in which ID field they pass to createProductGrantEntry. Extracting common logic would improve maintainability.

Consider creating a shared helper:

function buildPurchaseTransaction(options: {
  entity: Subscription | OneTimePurchase,
  idField: { subscriptionId?: string } | { oneTimePurchaseId?: string },
}): Transaction {
  const { entity, idField } = options;
  const customerType = typedToLowercase(entity.customerType);
  const product = entity.product as InferType<typeof productSchema> | null;
  const productSnapshot = ensureProductSnapshot(product, customerType);
  const selectedPrice = product ? resolveSelectedPriceFromProduct(product, entity.priceId ?? null) : null;
  const quantity = entity.quantity;
  const chargedAmount = buildChargedAmount(selectedPrice, quantity);
  const testMode = entity.creationSource === "TEST_MODE";

  const entries: TransactionEntry[] = [
    createProductGrantEntry({
      customerType,
      customerId: entity.customerId,
      productId: entity.productId ?? null,
      product: productSnapshot,
      priceId: entity.priceId ?? null,
      quantity,
      ...idField,
    }),
  ];

  const moneyTransfer = createMoneyTransferEntry({
    customerType,
    customerId: entity.customerId,
    chargedAmount,
    skip: testMode,
  });
  if (moneyTransfer) {
    entries.push(moneyTransfer);
  }

  return {
    id: entity.id,
    created_at_millis: entity.createdAt.getTime(),
    effective_at_millis: entity.createdAt.getTime(),
    type: "purchase",
    entries,
    adjusted_by: [],
    test_mode: testMode,
  };
}

export function buildSubscriptionTransaction(options: { subscription: Subscription }): Transaction {
  return buildPurchaseTransaction({
    entity: options.subscription,
    idField: { subscriptionId: options.subscription.id },
  });
}

export function buildOneTimePurchaseTransaction(options: { purchase: OneTimePurchase }): Transaction {
  return buildPurchaseTransaction({
    entity: options.purchase,
    idField: { oneTimePurchaseId: options.purchase.id },
  });
}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

packages/stack-shared/src/interface/admin-interface.ts (1)

598-611: Method signature correctly updated to new Transaction model.

The method signature, query construction, and return type are all correctly updated to use Transaction and TransactionType. The implementation properly handles optional parameters and builds the query string as needed.

Consider extracting customerType to a type definition similar to TransactionType for consistency:

In packages/stack-shared/src/interface/crud/transactions.ts, add:

export const CUSTOMER_TYPES = ['user', 'team', 'custom'] as const;
export type CustomerType = (typeof CUSTOMER_TYPES)[number];

Then update this method signature:

-async listTransactions(params?: { cursor?: string, limit?: number, type?: TransactionType, customerType?: 'user' | 'team' | 'custom' }): Promise<{ transactions: Transaction[], nextCursor: string | null }>
+async listTransactions(params?: { cursor?: string, limit?: number, type?: TransactionType, customerType?: CustomerType }): Promise<{ transactions: Transaction[], nextCursor: string | null }>

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

apps/dashboard/src/components/data-table/transaction-table.tsx (2)

192-356: Restore functional type filtering
The source_type column still returns SourceType values while the toolbar hands it TransactionType values and the API filter expects TransactionType. As soon as you pick a type, the table accessor never matches, so the UI shows an empty grid even though the backend returns data. We need this column (and all related wiring) to operate directly on transaction.type so the table, toolbar, and API stay in sync.

@@
-    {
-      id: 'source_type',
-      accessorFn: (transaction) => summaryById.get(transaction.id)?.sourceType ?? 'other',
+    {
+      id: 'type',
+      accessorFn: (transaction) => transaction.type,
       header: ({ column }) => <DataTableColumnHeader column={column} columnTitle="Type" />,
       cell: ({ row }) => {
         const summary = summaryById.get(row.original.id);
@@
-    const newFilters: { cursor?: string, limit?: number, type?: TransactionType, customerType?: 'user' | 'team' | 'custom' } = {
+    const newFilters: { cursor?: string, limit?: number, type?: TransactionType, customerType?: 'user' | 'team' | 'custom' } = {
       cursor: options.cursor,
       limit: options.limit,
-      type: options.columnFilters.find(f => f.id === 'source_type')?.value as any,
+      type: options.columnFilters.find(f => f.id === 'type')?.value as any,
       customerType: options.columnFilters.find(f => f.id === 'customer')?.value as any,
     };
@@
       defaultVisibility={{
-        source_type: true,
+        type: true,
         customer: true,
         amount: true,
         detail: true,
         created_at_millis: true,
       }}
       defaultColumnFilters={[
-        { id: 'source_type', value: undefined },
+        { id: 'type', value: undefined },
         { id: 'customer', value: undefined },
       ]}
@@
-      toolbarRender={(table) => {
-        const selectedType = table.getColumn('source_type')?.getFilterValue() as TransactionType | undefined;
+      toolbarRender={(table) => {
+        const typeColumn = table.getColumn('type');
+        const selectedType = typeColumn?.getFilterValue() as TransactionType | undefined;
@@
-            <Select
-              value={selectedType ?? ''}
-              onValueChange={(v) => table.getColumn('source_type')?.setFilterValue(v === '__clear' ? undefined : v)}
+            <Select
+              value={selectedType ?? ''}
+              onValueChange={(v) => typeColumn?.setFilterValue(v === '__clear' ? undefined : v)}
             >

---

131-139: Show real amounts for every currency
pickChargedAmountDisplay still hardcodes USD, so non-USD tenants see "Non USD amount" and USD entries with undefined amounts render as "$undefined". Please surface whichever currency actually has a value and fall back to '—' only when none do.

 function pickChargedAmountDisplay(entry: MoneyTransferEntry | undefined): string {
   if (!entry) return '—';
   const chargedAmount = entry.charged_amount as Record<string, string | undefined>;
-  if ("USD" in chargedAmount) {
-    return `$${chargedAmount.USD}`;
-  }
-  // TODO: Handle other currencies
-  return 'Non USD amount';
+  const [currency, amount] =
+    Object.entries(chargedAmount).find(([, value]) => typeof value === 'string' && value.length > 0) ?? [];
+  if (!currency || !amount) {
+    return '—';
+  }
+  return currency === 'USD' ? `$${amount}` : `${currency} ${amount}`;
 }

apps/e2e/tests/backend/endpoints/api/v1/internal/transactions.test.ts (3)

5-8: Consider stronger typing for payment configuration.

Using Record<string, any> for extraProducts and extraItems loses type safety and could hide configuration errors.

Consider defining explicit types that match the product and item schemas used in the actual payment configuration, or at minimum use Record<string, unknown> to force type narrowing at usage sites.

---

13-37: Consider extracting base payment configurations to module-level constants.

The baseProducts and baseItems are defined inline, which could lead to duplication if these configurations are needed in other test files or helper functions.

Extract these to module-level constants at the top of the file:

+const BASE_PRODUCTS = {
+  "sub-product": {
+    displayName: "Sub Product",
+    customerType: "user",
+    serverOnly: false,
+    stackable: false,
+    prices: {
+      monthly: { USD: "1000", interval: [1, "month"] },
+    },
+    includedItems: {},
+  },
+  "otp-product": {
+    displayName: "One-Time Product",
+    customerType: "user",
+    serverOnly: false,
+    stackable: false,
+    prices: {
+      single: { USD: "5000" },
+    },
+    includedItems: {},
+  },
+};
+
+const BASE_ITEMS = {
+  credits: { displayName: "Credits", customerType: "user" },
+};
+
 async function setupProjectWithPaymentsConfig(options: PaymentsConfigOptions = {}) {
   await Project.createAndSwitch();
   await PaymentsHelper.setup();
-  const baseProducts = {
-    "sub-product": { ... },
-    "otp-product": { ... },
-  };
-  const baseItems = {
-    credits: { displayName: "Credits", customerType: "user" },
-  };
   await Project.updateConfig({
     payments: {
       testMode: true,
       products: {
-        ...baseProducts,
+        ...BASE_PRODUCTS,
         ...(options.extraProducts ?? {}),
       },
       items: {
-        ...baseItems,
+        ...BASE_ITEMS,
         ...(options.extraItems ?? {}),
       },
     },
   });
 }

---

332-395: LGTM with optional readability improvement.

Excellent test coverage for customer_type filtering across multiple sources (purchases and item changes).

The nested every() assertions on lines 384-386 and 394 could be more readable:

- expect(teamResponse.body.transactions.every((tx: any) =>
-   tx.entries.every((entry: any) => entry.customer_type === "team")
- )).toBe(true);
+ const allTeamEntries = teamResponse.body.transactions
+   .flatMap((tx: any) => tx.entries)
+   .every((entry: any) => entry.customer_type === "team");
+ expect(allTeamEntries).toBe(true);

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro