-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Serverless Search] Index Management - Index Details Overview #173581
[Serverless Search] Index Management - Index Details Overview #173581
Conversation
.../serverless_search/public/application/components/index_management/connector_setup_prompt.tsx
Show resolved
Hide resolved
...lugins/serverless_search/public/application/components/index_management/api_empty_prompt.tsx
Outdated
Show resolved
Hide resolved
...lugins/serverless_search/public/application/components/index_management/api_empty_prompt.tsx
Outdated
Show resolved
Hide resolved
...s/serverless_search/public/application/components/index_management/overview_empty_prompt.tsx
Show resolved
Hide resolved
x-pack/plugins/serverless_search/public/application/hooks/api/use_create_connector.tsx
Outdated
Show resolved
Hide resolved
...ugins/serverless_search/public/application/components/connectors/empty_connectors_prompt.tsx
Show resolved
Hide resolved
.../serverless_search/public/application/components/index_management/connector_empty_prompt.tsx
Outdated
Show resolved
Hide resolved
const [aliasesFlyoutOpen, setAliasesFlyoutOpen] = React.useState<boolean>(false); | ||
const { data, isLoading, isError } = useIndex(index.name); | ||
const indexAliases = | ||
typeof index.aliases === 'string' |
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.
this logic could be removed if we add aliases to the fetchIndex
endpoint and just always return an array instead of the currently index management behavior or string | string[]
including "none"
when there are no aliases.
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.
Always returning an array would make more sense to me
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.
Thanks for copy ping @TattdCodeMonkey
...lugins/serverless_search/public/application/components/index_management/api_empty_prompt.tsx
Outdated
Show resolved
Hide resolved
...lugins/serverless_search/public/application/components/index_management/api_empty_prompt.tsx
Outdated
Show resolved
Hide resolved
...s/serverless_search/public/application/components/index_management/overview_empty_prompt.tsx
Show resolved
Hide resolved
@sphilipse any ideas on what in this PR made the bundle size |
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.
couple nits but looks good overall
x-pack/plugins/serverless_search/public/application/components/badge_list.tsx
Outdated
Show resolved
Hide resolved
.../serverless_search/public/application/components/index_management/connector_empty_prompt.tsx
Outdated
Show resolved
Hide resolved
const [aliasesFlyoutOpen, setAliasesFlyoutOpen] = React.useState<boolean>(false); | ||
const { data, isLoading, isError } = useIndex(index.name); | ||
const indexAliases = | ||
typeof index.aliases === 'string' |
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.
Always returning an array would make more sense to me
.../plugins/serverless_search/public/application/components/index_management/index_overview.tsx
Outdated
Show resolved
Hide resolved
client: ElasticsearchClient, | ||
indexName: string | ||
): Promise<FetchIndexResult | undefined> { | ||
const [indexData, indexStats, indexCount, connector] = await Promise.all([ |
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.
question: What happens if the index doesn't exist or Elasticsearch throws an error for a different reason (temporarily unavailable shards or whatever)?
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.
any error in any of these cause with cause this function to throw... which is not exactly ideal.
In practice currently if the index doesn't exist the frontend will never call this endpoint since the index management page will render an error and never render our detail component. BUT that not really good enough for this endpoint to have such poor error handling.
So how should we handle intermittent errors in serverless endpoints? we have utility functions in enterprise_search
to catch errors from library functions and return errors to the frontend. We haven't gotten that far in serverless search yet.
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.
I don't mind just surfacing the underlying Elasticsearch error. The reason we have those obfuscating errors in Search is that Enterprise Search can leak information we don't want to leak, but that's not really an issue for this.
Could we use .allSettled()
instead of .all()
so we return partial information when one call fails?
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.
using .allSettled()
is fine with me, will update.
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.
I updated this. My only concern is we're now swallowing errors if any of these calls fail (other than the get index) and we're not logging anything. which is something we should address later.
@TattdCodeMonkey looks like you pulled what was a lazy-loaded chunk into the initial page load bundle. Probably connectors got pulled into the main chunk instead of being lazy-loaded. |
.../serverless_search/public/application/components/index_management/connector_empty_prompt.tsx
Show resolved
Hide resolved
Importing the connector route paths from the router was causing our async chunks to explode in size. Moving these to the constants file instead resolved the chunking issue.
export const BadgeList = ({ badges, maxBadgesToDisplay }: BadgeListProps) => { | ||
const maxBadges = maxBadgesToDisplay ?? 3; | ||
if (badges.length === 0) { | ||
return <></>; |
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.
I'm not sure why I did this vs. return null;
but googling it it seems returning is fragment is possibly preferable for TS since the result is always JSX.Element
instead of JSX.Element | null
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsasync chunk count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
Summary
This PR implements a new Overview tab for an Index details in Index Management for Serverless.
It has data panels for information about the index and optional empty states if the index has no documents. (see Screenshots)
Screenshots
Index with data
Index without data
Connector Index without data
Checklist