apps/e2e/tests/backend/endpoints/api/v1/analytics-config.test.ts (1)

49-55: Prefer inline snapshots for config assertions.

Guidelines prefer toMatchInlineSnapshot for test assertions; this also makes diffs clearer when config shape changes.

Example refactor

-    expect(config.analytics.queryFolders[folderId]).toEqual({
-      displayName: "Test Folder",
-      sortOrder: 0,
-      queries: {},
-    });
+    expect(config.analytics.queryFolders[folderId]).toMatchInlineSnapshot(`
+      {
+        "displayName": "Test Folder",
+        "queries": {},
+        "sortOrder": 0,
+      }
+    `);

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/analytics/queries/page-client.tsx (3)

65-125: Consider extracting shared cell-formatting helpers.
isDateValue, parseClickHouseDate, JsonValue, and CellValue are duplicated across analytics tables and run-query previews; centralizing them in a shared helper/component would reduce drift.

---

403-407: Wrap dialog async actions with runAsynchronouslyWithAlert.
The dialog buttons pass async handlers directly; rejected promises can be unhandled and bypass alerting. Wrap the Create/Save/Delete actions with runAsynchronouslyWithAlert (example below shows Create).

🔧 Example adjustment

-          <Button onClick={handleCreate} disabled={!displayName.trim() || loading}>
+          <Button onClick={() => runAsynchronouslyWithAlert(handleCreate())} disabled={!displayName.trim() || loading}>
             {loading ? "Creating..." : "Create"}
           </Button>

As per coding guidelines, "Never try-catch-all, never void a promise, and never .catch(console.error) or similar. Use loading indicators instead when UI is involved. If async is necessary, use runAsynchronously or runAsynchronouslyWithAlert".

Also applies to: 496-500, 544-548

---

584-587: Use explicit error handling instead of silent fallbacks for missing config.

Replace the type assertion and silent fallbacks with ?? throwErr(...) to ensure config gaps are caught early. Import throwErr from @stackframe/stack-shared/dist/utils/errors and throw with a message explaining what's expected (e.g., "analytics.queryFolders not found in config").

- const analyticsConfig = (config as { analytics?: { queryFolders?: Record<string, ConfigFolder> } }).analytics ?? {};
- const queryFolders = analyticsConfig.queryFolders ?? {};
+ const analyticsConfig = config.analytics ?? throwErr("Missing analytics config");
+ const queryFolders = analyticsConfig.queryFolders ?? throwErr("Missing queryFolders in analytics config");

Alternatively, update the config type definition to properly reflect the expected structure.

apps/e2e/tests/backend/endpoints/api/v1/analytics-config.test.ts (1)

49-55: Prefer inline snapshots for config object assertions.
Using toMatchInlineSnapshot() here makes expected shapes clearer and aligns with the snapshot serializer used across tests.

♻️ Suggested change

-    expect(config.analytics.queryFolders[folderId]).toEqual({
-      displayName: "Test Folder",
-      sortOrder: 0,
-      queries: {},
-    });
+    expect(config.analytics.queryFolders[folderId]).toMatchInlineSnapshot(`
+      {
+        "displayName": "Test Folder",
+        "queries": {},
+        "sortOrder": 0,
+      }
+    `);

As per coding guidelines, prefer .toMatchInlineSnapshot over other selectors when writing tests; use the snapshot serializer format.

apps/dashboard/src/components/commands/run-query.tsx (1)

396-402: Replace the config cast with a typed analytics config.
The config as { analytics?: ... } cast sidesteps type safety and can mask schema drift now that analytics.queryFolders is part of the shared config. Prefer updating the config typing (or adding a narrow runtime guard) and then access config.analytics?.queryFolders directly.
As per coding guidelines: "Never silently use fallback values when type errors occur. Update types or throw errors instead. Use ?? throwErr(...) over non-null assertions with clear error messages explaining the assumption".

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/analytics/queries/page-client.tsx (1)

589-592: Prefer typed analytics config over casting.
The cast bypasses type safety now that analytics.queryFolders is part of the schema. Please update config typings (or add a narrow runtime guard) and access config.analytics?.queryFolders directly.
As per coding guidelines: "Never silently use fallback values when type errors occur. Update types or throw errors instead. Use ?? throwErr(...) over non-null assertions with clear error messages explaining the assumption".

apps/e2e/tests/backend/endpoints/api/v1/analytics-config.test.ts (1)

61-65: Prefer inline snapshots for object assertions.

This test uses toEqual with a full object. The test guideline prefers inline snapshots to keep expectations aligned with the snapshot serializer; consider switching here and mirroring across similar assertions in this file.

♻️ Suggested change

-    expect(config.analytics.queryFolders[folderId]).toEqual({
-      displayName: "Test Folder",
-      sortOrder: 0,
-      queries: {},
-    });
+    expect(config.analytics.queryFolders[folderId]).toMatchInlineSnapshot(`
+      {
+        "displayName": "Test Folder",
+        "queries": {},
+        "sortOrder": 0,
+      }
+    `);

As per coding guidelines: **/*.test.{ts,tsx}: Prefer .toMatchInlineSnapshot over other selectors when writing tests. Check snapshot-serializer.ts to understand how snapshots are formatted.

apps/dashboard/src/components/commands/run-query.tsx (1)

647-651: Consider using runAsynchronously instead of .catch(() => {}).

While the comment explains that errors are handled inside runQuery, the empty catch pattern is discouraged. Using runAsynchronously would be cleaner and self-documenting.

♻️ Optional refactor

+import { runAsynchronously } from "@stackframe/stack-shared/dist/utils/promises";
 ...
   const handleRetry = useCallback(() => {
-    runQuery().catch(() => {
-      // Error is already handled in runQuery
-    });
+    // Error is already handled in runQuery via setError
+    runAsynchronously(runQuery());
   }, [runQuery]);

apps/e2e/tests/backend/endpoints/api/v1/analytics-config.test.ts (2)

59-65: Prefer inline snapshots for object-shape assertions.
This aligns with the test guideline and reduces repetitive object literals in these config assertions.

---

306-341: Cascade-delete test doesn’t actually assert query override cleanup.
The test name says queries are deleted, but only the folder key is checked.

✅ Add explicit checks for query key cleanup

   // Verify folder is deleted (check override since rendered config applies defaults)
   const override = await getEnvironmentOverride(adminAccessToken);
   expect(override["analytics.queryFolders.cascade-folder"]).toBeNull();
+  expect(override["analytics.queryFolders.cascade-folder.queries.query-1"]).toBeUndefined();
+  expect(override["analytics.queryFolders.cascade-folder.queries.query-2"]).toBeUndefined();

apps/dashboard/src/components/commands/run-query.tsx (1)

655-659: Replace empty .catch() with runAsynchronouslyWithAlert.

The empty .catch(() => {}) silently swallows any errors that escape runQuery's internal try-catch. Per coding guidelines, avoid .catch(console.error) or similar patterns.

Since runQuery already handles expected errors via setError(), use runAsynchronouslyWithAlert to surface any unexpected failures.

♻️ Suggested refactor

  const handleRetry = useCallback(() => {
-   runQuery().catch(() => {
-     // Error is already handled in runQuery
-   });
+   runAsynchronouslyWithAlert(runQuery);
  }, [runQuery]);

As per coding guidelines: "Never try-catch-all, never void a promise, and never .catch(console.error) or similar."

packages/stack-shared/src/known-errors.tsx (1)

133-136: Prefer @ts-expect-error (or fix typing) instead of @ts-ignore.

Line 134 now uses @ts-ignore-next-line, which can silently mask real type errors. Please restore @ts-expect-error or tighten the typing so the directive isn’t needed.

🔧 Suggested minimal change

-      // `@ts-ignore` legendary comment, may never be removed https://x.com/konstiwohlwend/status/1998543556567617780
+      // `@ts-expect-error` legendary comment, may never be removed https://x.com/konstiwohlwend/status/1998543556567617780
       super(...createFn(...args));

apps/backend/prisma/migrations/20260202000000_fix_trusted_domains_config/migration.sql (1)

112-117: DROP INDEX should be schema-qualified for consistency.

The CREATE INDEX on Line 26 targets /* SCHEMA_NAME_SENTINEL */."EnvironmentConfigOverride", but the DROP INDEX on Line 116 uses an unqualified index name. While Postgres resolves index names via search_path, for consistency and to match the pattern used elsewhere in this migration, consider qualifying it.

Suggested fix

-DROP INDEX IF EXISTS "temp_eco_trusted_domains_checked_idx";
+DROP INDEX IF EXISTS /* SCHEMA_NAME_SENTINEL */."temp_eco_trusted_domains_checked_idx";

packages/stack-shared/src/config/schema.ts (1)

756-770: The lastWasFunction tracking logic is difficult to follow.

The comma-operator expression on Line 763 that sets lastWasFunction = true as a side effect inside a ternary is clever but impairs readability:

baseValue = has(baseValue, part) ? get(baseValue, part) : (typeof baseValue === 'function' ? (lastWasFunction = true, baseValue as any)(part) : undefined);

Consider splitting this into explicit if/else for clarity:

Suggested refactor

-        lastWasFunction = false;
-        baseValue = has(baseValue, part) ? get(baseValue, part) : (typeof baseValue === 'function' ? (lastWasFunction = true, baseValue as any)(part) : undefined);
+        if (has(baseValue, part)) {
+          lastWasFunction = false;
+          baseValue = get(baseValue, part);
+        } else if (typeof baseValue === 'function') {
+          lastWasFunction = true;
+          baseValue = (baseValue as any)(part);
+        } else {
+          lastWasFunction = false;
+          baseValue = undefined;
+        }

apps/dashboard/src/components/commands/run-query.tsx (1)

419-419: Unchecked as RowData[] cast on API response.

response.result is cast to RowData[] without validation. If the API returns an unexpected shape (e.g., not an array, or rows without string keys), downstream code will fail with confusing errors far from this line. Consider a runtime guard or at minimum an Array.isArray check.

Suggested minimal guard

-      const newRows = response.result as RowData[];
+      const newRows = response.result;
+      if (!Array.isArray(newRows)) {
+        throw new Error("Unexpected query result format: expected an array of rows");
+      }

As per coding guidelines: "Do NOT use as/any/type casts to bypass the type system unless you specifically asked the user about it. Most type casts are unnecessary." and "Code defensively… with good error messages explicitly stating assumptions."