Add page-level errors across admin UI

[jpople]

Ticket ENG-2244

Description Of Changes

Adds error pages to many/most pages in the admin UI if the primary query fails.

Also some updates to error page component:

• adds default error message
• shows "reload" action by default
• adds "show detail" for detailed error message

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

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

Project	Deployment	Review	Updated (UTC)
fides-plus-nightly	Error		Jan 7, 2026 6:52am

1 Skipped Deployment

Project	Deployment	Review	Updated (UTC)
fides-privacy-center	Ignored		Jan 7, 2026 6:52am

[greptile-apps]

Greptile Summary

This PR adds comprehensive page-level error handling across the admin UI to improve user experience when queries fail. The implementation follows a consistent pattern: pages check for errors from their data-fetching hooks and display an ErrorPage component with appropriate messaging.

Key changes:

• Enhanced ErrorPage component with default error messages, collapsible error details, and a reload button
• Added error handling to 40+ pages including user management, systems, datamap, properties, notifications, and action center pages
• Hooks expose error state from RTK Query to enable parent components to handle failures
• Comprehensive Cypress test coverage for error scenarios across action center pages

Minor concern:

• Properties page uses an inconsistent callback-based error handling pattern (onError prop with useEffect) instead of directly returning error from the hook like all other pages. This creates unnecessary complexity and deviates from the established pattern used consistently elsewhere in the codebase.

Confidence Score: 4/5

• This PR is safe to merge with minimal risk - adds defensive error handling across the UI
• Score reflects solid implementation with comprehensive test coverage. The only concern is an inconsistent error handling pattern in the properties page that uses callbacks instead of the standard hook return pattern used everywhere else. This doesn't introduce bugs but creates maintenance overhead and pattern inconsistency.
• Pay attention to clients/admin-ui/src/pages/properties/index.tsx and clients/admin-ui/src/features/properties/PropertiesTable.tsx which use a different error handling pattern than the rest of the codebase

Important Files Changed

Filename	Overview
clients/admin-ui/src/features/common/errors/ErrorPage.tsx	Enhanced error page component with default message, collapsible details, and reload button
clients/admin-ui/src/pages/user-management/index.tsx	Added error handling for user management page query failures
clients/admin-ui/src/pages/systems/index.tsx	Added error handling for systems page query failures
clients/admin-ui/src/pages/properties/index.tsx	Added callback-based error handling pattern for properties page - uses onError callback instead of hook
clients/admin-ui/src/features/properties/PropertiesTable.tsx	Implemented onError callback pattern with useEffect to pass errors up to parent
clients/admin-ui/src/pages/datamap/index.tsx	Added error handling for datamap page query failures

[greptile-apps]

_{51 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

style: Inconsistent error handling pattern. Most other pages (systems, user-management, datamap, etc.) extract the error directly from their hooks and check it in the page component. This page uses a callback pattern with useState and onError.

Consider refactoring to match the standard pattern:

Suggested change

	const [error, setError] = useState<
	FetchBaseQueryError | SerializedError | null
	>(null);
	const onError = useCallback((e: FetchBaseQueryError | SerializedError) => {
	setError(e);
	}, []);
	const PropertiesPage: NextPage = () => {
	const { error } = usePropertiesTable();
	const onError = useCallback((e: FetchBaseQueryError | SerializedError) => {
	setError(e);
	}, []);

Or better yet, refactor PropertiesTable to return the error like other hooks do, eliminating the callback entirely.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[greptile-apps]

style: Consider returning the error from the hook instead of using a callback pattern. This would align with the standard pattern used in other hooks like useUserManagementTable, useDatamapTable, etc., making the codebase more consistent and easier to maintain.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}