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));