Skip to content
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

Merged

Conversation

TattdCodeMonkey
Copy link
Contributor

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
image

Index without data
image
image
image

Connector Index without data
image

Checklist

@TattdCodeMonkey TattdCodeMonkey added release_note:skip Skip the PR/issue when compiling release notes Team:Search v8.13.0 labels Dec 18, 2023
@TattdCodeMonkey TattdCodeMonkey requested a review from a team December 18, 2023 22:15
const [aliasesFlyoutOpen, setAliasesFlyoutOpen] = React.useState<boolean>(false);
const { data, isLoading, isError } = useIndex(index.name);
const indexAliases =
typeof index.aliases === 'string'
Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Contributor

@leemthompo leemthompo left a 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

@TattdCodeMonkey
Copy link
Contributor Author

@sphilipse any ideas on what in this PR made the bundle size 439.4KB ?

Copy link
Member

@sphilipse sphilipse left a 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

const [aliasesFlyoutOpen, setAliasesFlyoutOpen] = React.useState<boolean>(false);
const { data, isLoading, isError } = useIndex(index.name);
const indexAliases =
typeof index.aliases === 'string'
Copy link
Member

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

client: ElasticsearchClient,
indexName: string
): Promise<FetchIndexResult | undefined> {
const [indexData, indexStats, indexCount, connector] = await Promise.all([
Copy link
Member

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)?

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

@sphilipse
Copy link
Member

@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.

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 <></>;
Copy link
Contributor Author

@TattdCodeMonkey TattdCodeMonkey Dec 19, 2023

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

@TattdCodeMonkey TattdCodeMonkey enabled auto-merge (squash) December 20, 2023 19:56
@TattdCodeMonkey
Copy link
Contributor Author

@elasticmachine merge upstream

@TattdCodeMonkey TattdCodeMonkey merged commit 5798255 into elastic:main Dec 20, 2023
35 checks passed
@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
serverlessSearch 326 336 +10

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
serverlessSearch 379.0KB 424.8KB +45.8KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
serverlessSearch 71.1KB 55.4KB -15.7KB
Unknown metric groups

async chunk count

id before after diff
serverlessSearch 4 7 +3

ESLint disabled line counts

id before after diff
serverlessSearch 4 6 +2

Total ESLint disabled count

id before after diff
serverlessSearch 4 6 +2

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Dec 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes Team:Search v8.13.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants