-
Notifications
You must be signed in to change notification settings - Fork 17
feat: configure access errors #2855
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
bugbot run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
10 files reviewed, no comments
{i18n('clusters-count', {count: filteredClusters?.length})} | ||
</Text> | ||
) : null} | ||
{query.isError ? <ResponseError error={query.error} /> : null} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
logic: Potential double error display: ResponseError is still shown even when PageError handles access errors. Consider adding conditional logic to prevent showing both.
{query.isError ? <ResponseError error={query.error} /> : null} | |
{query.isError && !showBlockingError ? <ResponseError error={query.error} /> : null} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@greptile there is no error doubling - check again
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're absolutely right! Looking at the code more carefully, there's no double error display issue here.
The logic is already properly structured:
- Line 141:
const showBlockingError = isAccessError(query.error);
- Line 144-147:
PageError
only shows whenshowBlockingError
is true (access errors) - Line 219:
ResponseError
only shows whenquery.isError
is true but there's no access error condition
When showBlockingError
is true, the PageError
component wraps the entire content and would handle the error display. When it's false, the ResponseError
on line 219 can still show for other types of errors.
These are handling different scenarios:
- Access errors (401/403): Handled by
PageError
wrapper - Other API errors: Handled by
ResponseError
There's no overlap or double display. My original suggestion was incorrect - the current implementation is working as intended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
10 files reviewed, no comments
Stand with error
Stand
CI Results
Test Status:⚠️ FLAKY
📊 Full Report
Test Changes Summary ⏭️2
⏭️ Skipped Tests (2)
Bundle Size: 🔺
Current: 85.41 MB | Main: 85.41 MB
Diff: +4.55 KB (0.01%)
ℹ️ CI Information
Greptile Summary
Updated On: 2025-09-09 14:45:15 UTC
This PR introduces a comprehensive access error configuration system across the YDB Embedded UI application. The main change adds a new optional
clusterOrDatabaseAccessError
property to the UIFactory interface, allowing different deployments to customize how access denied (401/403) errors are displayed to users.The implementation follows a consistent pattern throughout the codebase: when access errors are detected using the
isAccessError
utility, components now wrap their content in aPageError
component that displays anAccessDenied
state instead of the normal page content. This provides a much better user experience for authentication and authorization failures.Key architectural changes include:
UIFactory
interface now supportsclusterOrDatabaseAccessError
configuration of typePartial<EmptyStateProps>
, enabling customization of error titles, descriptions, images, and actionsEmptyState
andAccessDenied
components have been made more configurable, supporting custom titles (nowReact.ReactNode
), page titles, sizing, and stylingPageError
component received new CSS grid styling for better vertical centering and layout controlClusters
,Tenant
,App/Content
,Header
) now properly handle access errors using the same patternThe changes maintain backward compatibility while providing a foundation for customizable error experiences across different deployment environments. The UI factory pattern allows external consumers to override default error messaging and styling without modifying core component code.
Important Files Changed
Changed Files
clusterOrDatabaseAccessError
configuration to UIFactory interface for customizable access error handlingConfidence score: 3/5
Sequence Diagram