apps/web/lib/swr/use-partners-count.ts (1)

21-26: Potential serialization of undefined values as strings.

Spreading params directly into URLSearchParams will serialize any undefined values as the string "undefined". Consider filtering out undefined/null entries before constructing the query string:

   const queryString = ignoreParams
     ? // @ts-ignore
       `?${new URLSearchParams({
-        ...params,
+        ...Object.fromEntries(
+          Object.entries(params).filter(([, v]) => v != null)
+        ),
         workspaceId,
       }).toString()}`

packages/tinybird/pipes/v3_usage_latest.pipe (1)

104-108: Clarify link counting logic with uniq(*).

uniq(*) counts unique rows based on all selected columns. Since you're selecting from dub_links_metadata_latest FINAL, this effectively counts rows. If the intent is to count distinct links, consider using uniq(link_id) or count(*) for clarity:

     SELECT
         toDateTime64(toStartOfDay(timestamp, {{ String(timezone, 'UTC') }}), 3) AS interval,
         {% if defined(groupBy) %} {% if groupBy == 'folder_id' %} folder_id {% else %} domain {% end %}, {% end %}
-        uniq(*) as links
+        count(*) as links
     FROM dub_links_metadata_latest FINAL

apps/web/ui/shared/simple-date-range-picker.tsx (1)

70-73: Redundant type assertion.

The cast (presets as string[]) is unnecessary since presets is already typed as (typeof DATE_RANGE_INTERVAL_PRESETS)[number][], which should be compatible with string[].

-        ? INTERVAL_DISPLAYS.filter(({ value }) =>
-            (presets as string[]).includes(value),
-          )
+        ? INTERVAL_DISPLAYS.filter(({ value }) => presets.includes(value))

packages/ui/src/charts/bars.tsx (1)

74-74: Avoid as any[] type assertion.

The reduce accumulator is typed as any[], losing type safety. Consider defining an explicit type:

+            type StackedBar = {
+              id: string;
+              value: number;
+              colorClassName?: string;
+              styles?: { barClassName?: string; barFill?: string };
+              y: number;
+              height: number;
+            };
+
-            const bars = sortedSeries.reduce((acc, s) => {
+            const bars = sortedSeries.reduce<StackedBar[]>((acc, s) => {
               // ...
-            }, [] as any[]);
+            }, []);

apps/web/app/api/workspaces/[idOrSlug]/billing/usage/route.ts (1)

53-99: Domain grouping metadata is effectively unused and can be simplified

When groupBy === "domain":

• groupIds are derived from d[groupBy] where groupBy is "domain", so these are the Tinybird domain field values (slugs per usageResponse), not DB ids.
• The Prisma query uses where: { projectId: workspace.id, id: { in: groupIds } } and later groupMeta.find((g) => g.id === groupId), but groupId is a slug, so this find will almost always fail.
• As a result, name falls back to groupId, and the Prisma lookup does no real work for domains, while still adding a DB round-trip.

Given that the slug is already a good display label, you could either:

• Skip the Prisma query entirely for groupBy === "domain" and just use name: groupId, or
• If you actually want to look up by slug, change the query & lookup to use slug instead of id.

You might also want to filter out empty groupIds instead of including "" in the IN list and groups array, unless you explicitly want an “Unsorted” bucket.

Also applies to: 105-105

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/usage-chart.tsx (2)

143-172: Sort tooltip “top groups” by the hovered day’s values, not the first row’s usage

In the tooltip you compute:

const topGroups = usage?.[0]?.groups
  ?.filter((group) => d.values[group.id] > 0)
  .sort((a, b) => b.usage - a.usage)
  .slice(0, 8);

group.usage here is taken from the first data row (usage[0]), so the sort order reflects that first day rather than the hovered day d. Since you already have d.values[group.id], you can sort by that instead to make the ordering match what’s actually shown:

-  .sort((a, b) => b.usage - a.usage)
+  .sort((a, b) => d.values[b.id] - d.values[a.id])

This keeps the displayed values the same but makes the ranking per-day intuitive.

Also applies to: 222-247

---

155-172: Initialize groupsMeta so loading/error UI can actually render

groupsMeta is always an object:

const groupsMeta = useMemo(
  () =>
    Object.fromEntries(
      usage?.[0]?.groups?.map(/* ... */) ?? [],
    ),
  [usage],
);

Even when usage is undefined, this returns {}, which is truthy. That means the groupsMeta ? (…) : (…) branch later will always take the “truthy” side and the skeleton / “Failed to load usage data” UI is effectively unreachable.

If you want to show the loading skeleton until grouped data exists, consider something like:

-const groupsMeta = useMemo(
-  () =>
-    Object.fromEntries(
-      usage?.[0]?.groups?.map(/* ... */) ?? [],
-    ),
-  [usage],
-);
+const groupsMeta = useMemo(() => {
+  if (!usage?.[0]?.groups) return null;
+  return Object.fromEntries(
+    usage[0].groups.map((g, idx) => [/* ... */]),
+  );
+}, [usage]);

and keep the existing groupsMeta ? … : … conditional. That way, skeletons render while loading, and the error message shows if usage never arrives.

Also applies to: 315-391

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:180-189
Timestamp: 2025-09-24T15:50:16.414Z
Learning: TWilson023 prefers to keep security vulnerability fixes separate from refactoring PRs when the vulnerable code is existing and was only moved/relocated rather than newly introduced.

Learnt from: steven-tey
Repo: dubinc/dub PR: 2958
File: apps/web/app/app.dub.co/(dashboard)/[slug]/settings/members/page-client.tsx:432-457
Timestamp: 2025-10-15T01:05:43.266Z
Learning: In apps/web/app/app.dub.co/(dashboard)/[slug]/settings/members/page-client.tsx, defer refactoring the custom MenuItem component (lines 432-457) to use the shared dub/ui MenuItem component to a future PR, as requested by steven-tey.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2736
File: apps/web/lib/swr/use-bounty.ts:11-16
Timestamp: 2025-08-26T15:05:55.081Z
Learning: In the Dub codebase, workspace authentication and route structures prevent endless loading states when workspaceId or similar route parameters are missing, so gating SWR loading states on parameter availability is often unnecessary.

Learnt from: TWilson023
Repo: dubinc/dub PR: 3044
File: apps/web/lib/analytics/utils/get-interval-data.ts:31-0
Timestamp: 2025-10-31T19:45:25.702Z
Learning: In apps/web/lib/analytics/utils/get-interval-data.ts, the `mtd` and `qtd` interval functions are designed to work in both server and client contexts. When no timezone is provided, they intentionally fall back to `new Date()` (local timezone) because front-end code calls these methods without passing a timezone and should use the browser's local timezone for the user's context.

apps/web/app/api/workspaces/[idOrSlug]/billing/usage/route.ts (1)

80-92: Consider optimizing the nested loop structure for better performance.

The current implementation uses nested loops with filtering, resulting in O(dates × groups × data.length) complexity. For large datasets, this could become a performance bottleneck.

Consider pre-grouping the data for O(data.length) complexity:

// Build a lookup map first
const dataByDateAndGroup = new Map<string, Map<string, number>>();
for (const item of response.data) {
  const groupId = item[groupBy] ?? "";
  if (!dataByDateAndGroup.has(item.date)) {
    dataByDateAndGroup.set(item.date, new Map());
  }
  const groupMap = dataByDateAndGroup.get(item.date)!;
  groupMap.set(groupId, (groupMap.get(groupId) ?? 0) + item.value);
}

// Then build the response
data = dates.map((date) => {
  const groupMap = dataByDateAndGroup.get(date) ?? new Map();
  const groups = groupIds.map((groupId) => ({
    id: groupId,
    name: groupMeta.find((g) => g.id === groupId)?.[
      groupBy === "folder_id" ? "name" : "slug"
    ] ?? groupId,
    usage: groupMap.get(groupId) ?? 0,
  }));

  return {
    date,
    value: sum(groups.map((g) => g.usage)),
    groups,
  };
});

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:180-189
Timestamp: 2025-09-24T15:50:16.414Z
Learning: TWilson023 prefers to keep security vulnerability fixes separate from refactoring PRs when the vulnerable code is existing and was only moved/relocated rather than newly introduced.

packages/ui/src/charts/bars.tsx (3)

36-49: Per‑date value sorting changes vertical stack order; confirm this matches UX/legend expectations

Right now each date’s stack is ordered by valueAccessor(d) descending:

• Line [54] filters to valueAccessor(d) > 0, then
• Line [56] sorts by b.valueAccessor(d) - a.valueAccessor(d).

Because you then accumulate from bottom to top, the largest series for that date ends up at the bottom and the smallest at the top (which gets the rounded radius). This means the vertical position of a given series’ color can change from bucket to bucket depending on its relative value, even though the legend and series array likely have a fixed order.

If the design intent is for each series to occupy a stable vertical band across time (easier to read / match to legend), consider dropping the per‑date value sort and instead preserve the original series order (or a fixed explicit order), e.g.:

-            const sortedSeries = activeSeries
-              .filter((s) => s.valueAccessor(d) > 0)
-              .sort((a, b) => b.valueAccessor(d) - a.valueAccessor(d));
+            const sortedSeries = activeSeries.filter(
+              (s) => s.valueAccessor(d) > 0,
+            );

If the “largest at bottom” behavior is intentional for this chart, it’d be good to document that somewhere near this block or in the chart component’s props to avoid surprises for future callers.

Also applies to: 50-57, 76-97

---

50-53: Tighten up accumulator typing and avoid repeated reductions in stack computation

The stacking math looks correct, but there are a couple of maintainability/perf nits here:

• Line [58] initializes bars as [] as any[], losing all type safety for the computed segments.
• Line [59] recomputes stackHeight on every iteration via acc.reduce((sum, b) => sum + b.height, 0), even though stackHeight is just the running sum of heights you’re already computing.
• seriesStyles?.find(({ id }) => id === s.id) is run for every segment in every bucket; if seriesStyles grows, an indexed lookup would be clearer and cheaper.

A small refactor could make this more readable and typed without changing behavior. For example:

-            const bars = sortedSeries.reduce((acc, s) => {
-              const stackHeight = acc.reduce((sum, b) => sum + b.height, 0);
-              const value = s.valueAccessor(d) ?? 0;
-              const y = yScale(value);
-
-              return [
-                ...acc,
-                {
-                  id: s.id,
-                  value,
-                  colorClassName: s.colorClassName,
-                  styles: seriesStyles?.find(({ id }) => id === s.id),
-                  y: stackHeight, // y from x axis to bottom of bar
-                  height: height - y, // height from bottom to top of bar
-                },
-              ];
-            }, [] as any[]);
+            type BarSegment = {
+              id: string;
+              value: number;
+              colorClassName?: string;
+              styles?: (typeof seriesStyles)[number];
+              y: number;      // offset from x axis to bottom of bar (px)
+              height: number; // segment height (px)
+            };
+
+            let stackHeight = 0;
+            const bars: BarSegment[] = sortedSeries.map((s) => {
+              const value = s.valueAccessor(d) ?? 0;
+              const yVal = yScale(value);
+              const heightPx = height - yVal;
+
+              const bar: BarSegment = {
+                id: s.id,
+                value,
+                colorClassName: s.colorClassName,
+                styles: seriesStyles?.find(({ id }) => id === s.id),
+                y: stackHeight,
+                height: heightPx,
+              };
+
+              stackHeight += heightPx;
+              return bar;
+            });

(You could also precompute a Map for seriesStyles outside the data.map loop if this path ever becomes hot.)

Not mandatory for correctness, but it will make the stacking logic easier to reason about and less error‑prone if it evolves.

Also applies to: 58-75, 78-93

---

50-53: Consider failing fast instead of silently falling back when xScale(d.date) is undefined

Line [52] uses:

const x = xScale(d.date) ?? 0;

If, for whatever reason, d.date isn’t in the x‑scale’s domain, this will quietly render the bar at x = 0 instead of skipping the datum or surfacing the issue. That can make data/domain mismatches hard to spot.

If you expect data and xScale to always be in sync, consider an explicit guard:

const xVal = xScale(d.date);
if (xVal == null) return null; // or skip this <g> entirely
const x = xVal;

That way, a broken invariant doesn’t produce misleading bars at the origin.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
Repo: dubinc/dub PR: 3044
File: apps/web/lib/analytics/utils/get-interval-data.ts:31-0
Timestamp: 2025-10-31T19:45:25.702Z
Learning: In apps/web/lib/analytics/utils/get-interval-data.ts, the `mtd` and `qtd` interval functions are designed to work in both server and client contexts. When no timezone is provided, they intentionally fall back to `new Date()` (local timezone) because front-end code calls these methods without passing a timezone and should use the browser's local timezone for the user's context.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:180-189
Timestamp: 2025-09-24T15:50:16.414Z
Learning: TWilson023 prefers to keep security vulnerability fixes separate from refactoring PRs when the vulnerable code is existing and was only moved/relocated rather than newly introduced.

packages/ui/src/charts/use-tooltip.ts (1)

128-128: Remove debug console.log statement.

This appears to be leftover debug code that should be removed before merging.

Apply this diff:

       if (x0 === undefined) {
-        console.log("x0 is undefined", { defaultTooltipData });
         if (defaultTooltipData) visxTooltip.showTooltip(defaultTooltipData);
         else visxTooltip.hideTooltip();
         return;

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/usage-chart.tsx (1)

133-133: Remove unused activeResource from dependency array.

activeResource is included in the dependency array but is not referenced within the memo body. This causes unnecessary recalculations.

-    [activeResource, folders, domains],
+    [folders, domains],

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:180-189
Timestamp: 2025-09-24T15:50:16.414Z
Learning: TWilson023 prefers to keep security vulnerability fixes separate from refactoring PRs when the vulnerable code is existing and was only moved/relocated rather than newly introduced.

Learnt from: steven-tey
Repo: dubinc/dub PR: 2958
File: apps/web/app/app.dub.co/(dashboard)/[slug]/settings/members/page-client.tsx:432-457
Timestamp: 2025-10-15T01:05:43.266Z
Learning: In apps/web/app/app.dub.co/(dashboard)/[slug]/settings/members/page-client.tsx, defer refactoring the custom MenuItem component (lines 432-457) to use the shared dub/ui MenuItem component to a future PR, as requested by steven-tey.

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/usage-chart.tsx (2)

141-143: Unnecessary dependency in useMemo.

activeResource is listed in the dependency array but isn't used in the filter computation. This can cause unnecessary recalculations.

     ],
-    [activeResource, folders, domains],
+    [folders, domains],
   );

---

285-295: Missing scroll: false in groupBy toggle.

The other filter handlers use scroll: false to prevent unexpected page scrolling. This should be consistent.

           selectAction={(id) => queryParams({ set: { groupBy: id } })}
+          selectAction={(id) => queryParams({ set: { groupBy: id }, scroll: false })}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:180-189
Timestamp: 2025-09-24T15:50:16.414Z
Learning: TWilson023 prefers to keep security vulnerability fixes separate from refactoring PRs when the vulnerable code is existing and was only moved/relocated rather than newly introduced.

Learnt from: steven-tey
Repo: dubinc/dub PR: 2958
File: apps/web/app/app.dub.co/(dashboard)/[slug]/settings/members/page-client.tsx:432-457
Timestamp: 2025-10-15T01:05:43.266Z
Learning: In apps/web/app/app.dub.co/(dashboard)/[slug]/settings/members/page-client.tsx, defer refactoring the custom MenuItem component (lines 432-457) to use the shared dub/ui MenuItem component to a future PR, as requested by steven-tey.

apps/web/app/api/workspaces/[idOrSlug]/billing/usage/route.ts (1)

53-62: Null/undefined groupBy values still handled with empty string fallback.

The code still uses ?? "" which adds empty strings to groupIds when d[groupBy] is null/undefined. This empty string is then passed to the Prisma query's id: { in: groupIds } clause.

Filter out null/undefined values explicitly:

-  const groupIds = [...new Set(response.data.map((d) => d[groupBy] ?? ""))];
+  const groupIds = [
+    ...new Set(
+      response.data
+        .map((d) => d[groupBy])
+        .filter((id): id is string => Boolean(id)),
+    ),
+  ];

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/usage-chart.tsx (1)

223-241: Color inconsistency: hoveredGroupsMeta assigns colors by day-specific index.

This assigns colorClassName based on the hovered day's group ordering, which could differ from the stable groupsMeta ordering. However, since colorClassName from hoveredGroupsMeta is never actually used (only total is accessed at line 473), this is effectively dead code.

Consider removing the unused colorClassName to avoid confusion:

   return Object.fromEntries(
-    dayUsage.groups.map((g, idx) => [
+    dayUsage.groups.map((g) => [
       g.id,
       {
         name: g.name,
-        colorClassName: BAR_COLORS[idx % BAR_COLORS.length],
         total: g.usage,
       },
     ]),
   );

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/usage-chart.tsx (2)

105-145: Unused dependency in useMemo.

activeResource is included in the dependency array but is not used within the memo body. This causes unnecessary recalculations when activeResource changes.

   ],
-  [activeResource, folders, domains],
+  [folders, domains],
 );

---

573-582: Modal content may clip without scroll.

Using overflow-hidden on a container with max-h-[70vh] could clip content if the BarList exceeds the viewport height without providing scroll access.

-          <div className="max-h-[70vh] overflow-hidden">
+          <div className="max-h-[70vh] overflow-y-auto">

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:180-189
Timestamp: 2025-09-24T15:50:16.414Z
Learning: TWilson023 prefers to keep security vulnerability fixes separate from refactoring PRs when the vulnerable code is existing and was only moved/relocated rather than newly introduced.

Learnt from: devkiran
Repo: dubinc/dub PR: 2754
File: apps/web/lib/partnerstack/schemas.ts:47-52
Timestamp: 2025-08-16T11:14:00.667Z
Learning: The PartnerStack API always includes the `group` field in partner responses, so the schema should use `.nullable()` rather than `.nullish()` since the field is never omitted/undefined.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2736
File: apps/web/lib/api/bounties/get-bounty-or-throw.ts:53-63
Timestamp: 2025-08-26T15:38:48.173Z
Learning: In bounty-related code, getBountyOrThrow returns group objects with { id } field (transformed from BountyGroup.groupId), while other routes working directly with BountyGroup Prisma records use the actual groupId field. This is intentional - getBountyOrThrow abstracts the join table details.

Learnt from: steven-tey
Repo: dubinc/dub PR: 2958
File: apps/web/app/app.dub.co/(dashboard)/[slug]/settings/members/page-client.tsx:432-457
Timestamp: 2025-10-15T01:05:43.266Z
Learning: In apps/web/app/app.dub.co/(dashboard)/[slug]/settings/members/page-client.tsx, defer refactoring the custom MenuItem component (lines 432-457) to use the shared dub/ui MenuItem component to a future PR, as requested by steven-tey.