feat(observability): consolidate observability UI updates - #1975

Check if this issue is valid — if so, understand the root cause and fix it. At apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/observability/issues/stack-frame-list.tsx, line 186:

<comment>When occurrence navigation changes an all-library run to the same run followed by an app frame, this key stays unchanged although `defaultExpanded` changes. React preserves `CollapsedFrameGroup`'s old `expanded` state, so the new occurrence ignores its default; include `defaultExpanded` and the complete run identity in the key.</comment>

<file context>
@@ -163,7 +177,13 @@ export function StackFrameList({
+              // default) onto a DIFFERENT frame run after occurrence
+              // navigation swaps the stack. First/last location plus length is
+              // enough to distinguish runs without hashing every frame.
+              key={`collapsed-${group.startIndex}-${group.frames.length}-${frameLocationLabel(group.frames[0] ?? throwMissingCollapsedFrame())}-${frameLocationLabel(group.frames[group.frames.length - 1] ?? throwMissingCollapsedFrame())}`}
               frames={group.frames}
               defaultExpanded={group.defaultExpanded}
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/analytics/paths/normalize-url.ts, line 22:

<comment>16–19-character URL-safe base64 IDs are no longer normalized, so routes containing them remain split instead of grouping by route shape. The `api` and `auth` examples already fail the 16-character regex; keep the runtime check aligned with `BASE64_TOKEN_REGEX` and add a regression test for the intended minimum.</comment>

<file context>
@@ -4,45 +4,36 @@
 
-  // Base64 tokens (only for longer segments to avoid false positives on
-  // short path segments like "api" or "auth")
+  // Length 20, not the regex's 16: shorter base64-shaped words (`api`, `auth`)
+  // would otherwise collapse into `:id`.
   if (segment.length >= 20 && BASE64_TOKEN_REGEX.test(segment)) return true;
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/observability/releases/page-client.tsx, line 287:

<comment>When an add-commit request completes after the admin selects another release, this guard leaves the new release selected, but the following setters clear its form and show a success notice for the old release. Guard the commit form resets and notice with the same stale-operation check.</comment>

<file context>
@@ -270,7 +279,12 @@ export default function PageClient() {
+      // flight, and unconditionally setting would yank the view back to the
+      // release the commit was added to.
+      const refreshedRelease = await fetchReleaseByVersion(adminApp, selectedRelease.version);
+      setSelectedRelease((current) => (current?.id === refreshedRelease.id ? refreshedRelease : current));
       setCommitSha("");
       setCommitMessage("");
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/observability/traces/page-client.tsx, line 790:

<comment>When a trace has more than 10,000 spans, events from spans after the retained oldest 10,000 are omitted from the waterfall. Extend the event window to the current time, or obtain the uncapped trace interval, whenever the span result is capped.</comment>

<file context>
@@ -738,28 +764,53 @@ export default function PageClient() {
+        // Open spans (endMs == null) extend the interval to "now". A capped
+        // trace can under-report its true end; the capped-trace alert already
+        // flags that view as partial.
+        const spanEndMs = Math.max(...spans.map((span) => span.endMs ?? loadedAtMs));
+        const eventQuery = getSelectedTraceEventQuery(traceId, highlightEventAtMs, {
+          // A deep-linked highlight timestamp widens the window so clock skew
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/observability/issues/page-client.tsx, line 251:

<comment>When a list refresh completes while a status PATCH is pending, this reverse adjustment applies to fresh server counts instead of the optimistic baseline, so the status tabs can show incorrect totals. Track whether the optimistic delta is still present before undoing it, or reconcile with a fresh server response.</comment>

<file context>
@@ -193,19 +221,37 @@ export default function PageClient() {
       // Narrow catch around one call: revert and surface. Never swallowed, and
       // never a toast — a failed state change must stay on screen.
       setOverrides(clearOptimisticStatus(overridesRef.current, issue.id));
+      setCounts((current) => adjustIssueStatusCounts(current, status, from));
       setStatusError(error instanceof Error ? error.message : String(error));
+    } finally {
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/observability/traces/page-client.tsx, line 813:

<comment>When a trace has exactly 1,000 span links, this condition still shows a warning claiming that further links exist. Fetch one extra row and compare with the cap, or use a count query before setting this flag.</comment>

<file context>
@@ -738,28 +764,53 @@ export default function PageClient() {
         .map(parseTraceLinkRow)
         .filter((link): link is TraceLink => link != null));
       setTraceResultWasCapped(spansResponse.result.length >= 10000);
+      setLinksResultWasCapped(linksResponse.result.length >= SPAN_LINKS_CAP);
       setNowMs(Date.now());
     } catch (e) {
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/observability/format.ts, line 72:

<comment>At the top of the k range the output rolls over to "1000k" rather than into M. `formatCount(999_500)` produces "1000k" because `(value/1000).toFixed(0)` rounds to 1000 and the `k` suffix is appended, while the M branch handles its own rollover gracefully (`9_999_999` → "10.0M"). The two magnitude branches are inconsistent: the k branch never carries the decimal at its top, so it prints the malformed "1000k" instead of "1.0M". Guard the `k` result so it rolls into M when it rounds to 1000.</comment>

<file context>
@@ -51,6 +55,24 @@ export function formatDuration(ms: number | null): string {
+  if (!Number.isFinite(value)) throw new Error(`Cannot format a non-finite count: ${value}`);
+  if (value < 0) throw new Error(`Cannot format a negative count: ${value}`);
+  if (value < 10_000) return value.toLocaleString();
+  if (value < 1_000_000) return `${(value / 1_000).toFixed(value < 100_000 ? 1 : 0)}k`;
+  return `${(value / 1_000_000).toFixed(value < 10_000_000 ? 1 : 0)}M`;
+}
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/observability/releases/page-client.tsx, line 287:

<comment>The guarded-refresh pattern is now duplicated verbatim between addCommit and addDeployment (fetch by selectedRelease.version, then setSelectedRelease with the id-match guard). Consider extracting a small `refreshSelectedRelease(refreshedRelease)` helper so the stale-selection logic stays in one place and is used consistently (the create path still sets selectedRelease unconditionally).</comment>

<file context>
@@ -270,7 +279,12 @@ export default function PageClient() {
+      // flight, and unconditionally setting would yank the view back to the
+      // release the commit was added to.
+      const refreshedRelease = await fetchReleaseByVersion(adminApp, selectedRelease.version);
+      setSelectedRelease((current) => (current?.id === refreshedRelease.id ? refreshedRelease : current));
       setCommitSha("");
       setCommitMessage("");
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/observability/issues/use-issue-data.ts, line 173:

<comment>The sparkline grid is anchored to the browser's `Date.now()`, but the query window is anchored to the server's `now64(3)`. If the two clocks disagree by more than one bucket step (an hour on the 24h range, a minute on the 1h range), the newest server bucket falls outside the client-rebuilt grid and is silently dropped by the bounds check, so the most recent activity vanishes with no error surfaced. This mirrors the existing services `buildServiceTimelines`, which has the same skew dependency, but the added `Date.now()`-based grid here reintroduces it for issues. Anchoring to server time (e.g. snapping via the same `now64(3)` the query uses, or deriving `nowMs` from the returned data) would avoid the silent loss; at minimum, document the skew assumption rather than treating the drop as only the intentional partial-bucket clipping.</comment>

<file context>
@@ -166,7 +170,7 @@ export function useIssueSparklines(
         const { query, params } = getIssueSparklineQuery(hours, wanted);
         const response = await queryObservability(adminApp, { query, params });
-        const parsed = parseIssueSparklineRows(response.result, wanted);
+        const parsed = parseIssueSparklineRows(response.result, wanted, hours, Date.now());
         if (cancelled) return;
         setError(null);
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/observability/issues/page-client.tsx, line 86:

<comment>This re-implements the namespaced select-value codec that already exists for the service filter in `service-identity.ts`. The environment variant is simpler (plain string rather than an object) but the sentinel/prefix convention is duplicated in the page component instead of next to that codec, risking drift. Consider colocating the environment codec with service-identity's or documenting the shared convention.</comment>

<file context>
@@ -71,7 +76,28 @@ import { useIssueFacets, useIssueSparklines } from "./use-issue-data";
+ * dropdown — the URL codec and the API both carry the raw environment name.
+ */
 const ALL_ENVIRONMENTS_SELECT_VALUE = "all";
+const ENVIRONMENT_SELECT_VALUE_PREFIX = "env:";
+
+function environmentToSelectValue(environment: string | null): string {
</file context>