feat: render oops errors

[adityathebe]

resolves: #2723

Summary by CodeRabbit

• Bug Fixes

  • Improved error handling with more robust response parsing and structured error messaging across views.

• Style

  • Standardized error display UI using a unified component for consistent error presentation throughout the application.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
aws-preview	Ready	Preview	Dec 4, 2025 11:41am
flanksource-ui	Ready	Preview	Dec 4, 2025 11:41am

[coderabbitai]

Walkthrough

This PR enhances error handling across the views domain by strengthening the API service's fetchViewData function with defensive JSON parsing and structured error objects, then standardizes error display across multiple view pages and components by replacing inline error renderings with the ErrorViewer component.

Changes

Cohort / File(s)	Change Summary
API Service Enhancement src/api/services/views.ts	Enhanced error handling in fetchViewData: now performs defensive JSON parsing on non-OK responses with graceful fallback to null, and throws either parsed error objects or structured errors with message, status, and statusText; success path validates response data for embedded errors before returning.
View Components Error Display src/pages/audit-report/components/View/View.tsx, src/pages/views/ViewPage.tsx, src/pages/views/components/SingleView.tsx, src/pages/views/components/ViewSection.tsx	Unified error display across view pages and components by importing and using ErrorViewer component; error state type changed to unknown | null; composite error message handling added to extract error details (message, error, detail, msg) with fallback messaging; inline error UI replaced with consistent ErrorViewer component styling.

Possibly related PRs

• feat: Error viewer component #2746: Introduces the ErrorViewer component that this PR imports and uses across multiple view pages and components for standardized error display.
• feat: view sections #2739: Centralized fetchViewData function implementation; the enhanced error parsing and throwing in this PR's API service changes build upon that foundation.

Suggested reviewers

• moshloop

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title 'feat: render oops errors' clearly and concisely describes the main change: implementing error rendering for oops error responses in the Views feature using ErrorViewer components.
Linked Issues check	✅ Passed	The PR successfully addresses issue #2723 by implementing ErrorViewer components across all affected view pages and components to display structured error responses with context, error messages, and stacktraces.
Out of Scope Changes check	✅ Passed	All changes in the PR are directly scoped to handling oops error responses in view-related files; no unrelated modifications are present outside the error-rendering scope.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/view-error-rendering

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/pages/views/components/SingleView.tsx (1)

72-79: Consider simplifying error property extraction.

The manual extraction of error properties (message, error, detail, msg) here may be redundant. Based on the relevant code snippet, toastError already handles extracting response?.data?.error and response?.data?.message from error objects. You might be able to simplify this by passing result.error directly to toastError, unless you've confirmed that these specific properties aren't handled by the existing error handling chain.

Apply this diff if the toastError function handles these cases:

     if (result.isError) {
-      const err = result.error as any;
       toastError(
-        err?.message ||
-          err?.error ||
-          err?.detail ||
-          err?.msg ||
-          "Failed to refresh view"
+        result.error || "Failed to refresh view"
       );
       return;
     }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2785a80 and 1422688.

📒 Files selected for processing (5)

• src/api/services/views.ts (1 hunks)
• src/pages/audit-report/components/View/View.tsx (2 hunks)
• src/pages/views/ViewPage.tsx (4 hunks)
• src/pages/views/components/SingleView.tsx (4 hunks)
• src/pages/views/components/ViewSection.tsx (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (4)

src/pages/views/components/SingleView.tsx (2)

src/components/Toast/toast.ts (1)

• toastError (15-25)

src/components/ErrorViewer.tsx (1)

• ErrorViewer (68-115)

src/pages/audit-report/components/View/View.tsx (1)

src/components/ErrorViewer.tsx (1)

• ErrorViewer (68-115)

src/pages/views/components/ViewSection.tsx (1)

src/components/ErrorViewer.tsx (1)

• ErrorViewer (68-115)

src/pages/views/ViewPage.tsx (1)

src/components/ErrorViewer.tsx (1)

• ErrorViewer (68-115)

🔇 Additional comments (6)

src/api/services/views.ts (2)

93-100: LGTM! Defensive error handling.

The defensive JSON parsing with fallback to a structured error object ensures consistent error propagation even when the response body is malformed or non-JSON.

---

103-109: Error detection approach is correct per API design.

This properly detects both HTTPError and OopsError responses (both defined with error as their primary field in src/api/types/error.ts). The pattern of checking for the error property is the standard way the backend indicates errors in 200 OK responses. By throwing the entire data object, you preserve all available context including code, public message, hint, stacktrace, trace, and other diagnostic fields for error handling.

src/pages/audit-report/components/View/View.tsx (1)

259-263: LGTM! Consistent error rendering.

The replacement of inline error text with ErrorViewer provides a consistent, user-friendly error display that can show details (including stacktraces for "oops" errors) in a collapsible section.

src/pages/views/components/SingleView.tsx (1)

135-135: LGTM! Consistent error rendering with ErrorViewer.

Both error and not-found states now use ErrorViewer for consistent, user-friendly error display.

Also applies to: 148-151

src/pages/views/components/ViewSection.tsx (1)

77-82: LGTM! Consistent error rendering within sections.

The ErrorViewer integration provides a consistent error display for section loading failures, maintaining the collapsible section structure while improving error presentation.

src/pages/views/ViewPage.tsx (1)

26-26: LGTM! Improved type safety and consistent error rendering.

The changes improve error handling in multiple ways:

• The error state type change to unknown (line 26) aligns with ErrorViewer's flexible error handling.
• Simplified error catching (line 61) reduces complexity.
• Consistent ErrorViewer usage for both error states provides a unified error presentation.

Also applies to: 61-61, 80-93

[netlify]

❌ Deploy Preview for flanksource-demo-stable failed. Why did it fail? →

Name	Link
🔨 Latest commit	1422688
🔍 Latest deploy log	https://app.netlify.com/projects/flanksource-demo-stable/deploys/69317287a7dcc80008957303

[netlify]

❌ Deploy Preview for clerk-saas-ui failed. Why did it fail? →

Name	Link
🔨 Latest commit	1422688
🔍 Latest deploy log	https://app.netlify.com/projects/clerk-saas-ui/deploys/693172878ea02d000715397b