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

[investigate] Copy changes from POC #187936

Merged
merged 8 commits into from
Jul 16, 2024
Merged

Conversation

kdelemme
Copy link
Contributor

@kdelemme kdelemme commented Jul 10, 2024

Summary

Copy investigate/ plugin changes from #183293 into this PR.
Will follow up with the new plugin investigate_app/

Nothing to test here, it's just a public plugin exposing some hook and registry. Not used yet

@obltmachine
Copy link

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

  • /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
  • run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

@kdelemme kdelemme marked this pull request as ready for review July 10, 2024 07:56
@kdelemme kdelemme requested a review from a team as a code owner July 10, 2024 07:56
@kdelemme kdelemme self-assigned this Jul 10, 2024
@kdelemme kdelemme added release_note:skip Skip the PR/issue when compiling release notes Team:obs-ux-management Observability Management User Experience Team v8.16.0 labels Jul 10, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

@botelastic botelastic bot added the ci:project-deploy-observability Create an Observability project label Jul 10, 2024
@kdelemme kdelemme requested a review from a team as a code owner July 10, 2024 09:23
@kdelemme kdelemme requested a review from a team as a code owner July 10, 2024 12:50
@kdelemme kdelemme removed request for a team July 10, 2024 12:50
Comment on lines +41 to 58
register: (callback) => {
const registrationPromise = Promise.race([
callback(this.widgetRegistry.registerWidget),
new Promise<void>((resolve, reject) => {
setTimeout(() => {
reject(new Error('Timed out running registration function'));
}, 30000);
}),
]).catch((error) => {
this.logger.error(
new Error('Encountered an error during widget registration', { cause: error })
);
return Promise.resolve();
});

this.registrationPromises.push(registrationPromise);
},
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an opportunity here for a race condition: register is asynchronous, but getWidgetDefinitions is not. In practice you will probably never run into it, but it might become an issue for tests. You could consider making an Observable out of getWidgetDefinitions but there are some implications for code downstream.

@@ -20,15 +20,17 @@ import type {
export type { InvestigatePublicSetup, InvestigatePublicStart, OnWidgetAdd, WidgetRenderAPI };

export {
type InvestigateTimeline,
type Investigation,
Copy link
Contributor

@mgiota mgiota Jul 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering why we export these types from both public and common folders? I was looking into the consumer side where it is imported from and in some places we import it from common '@kbn/investigate-plugin/common';, where as in others from public '@kbn/investigate-plugin/public';

nit: Maybe we can keep only one place where we export/import from, unless there is a restriction I am not aware of.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is for other plugins to import it (without extra config, other plugins cannot import from /common). the difference that you see might be based on type imports vs code imports.

export interface Investigation {
id: string;
'@timestamp': number;
user: AuthenticatedUser;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once we have the concept of more users participating in one investigation, do we consider having here an array of authenticated users? Or possibly we could have an extra field invitedUsers. This is definitely not part of version 1, but I am trying to think about what we might introduce in the future that could shape the Investigation interface.

defaultMessage: 'New investigation',
}),
revision: revisionId,
revisions: [revision],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I understand correctly that we add to the revisions array only the latest revision? I thought we might want to have a list of all revisions. Do I miss something here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is an Investigation, and an InvestigationRevision, the former contains the latter. (eg. investigation.revisions)

> {
onWidgetAdd: (create: InvestigateWidgetCreate) => Promise<void>;
blocks: {
publish: (blocks: WorkflowBlock[]) => UnregisterBlocksFunction;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just weird that a publish function returns an unregisterBlocksFunction.

Maybe not as part of this PR, but let's think more about WorkflowBlock interface and map it to the mock up designs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's so you can use it in a useEffect hook


const InvestigateWidgetApiContext = createContext<UseInvestigateWidgetApi | undefined>(undefined);

export const InvestigateWidgetApiContextProvider = InvestigateWidgetApiContext.Provider;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dgieselaar Is this actually used anywhere? I was looking into the inital PR of how it is being used, but I didn't find any use of it, other than being exported here. If it is not being used, then we could remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it isn't, but I did discuss it with Kevin & Bena: I think context in this case is better than prop drilling, so I would use this API instead

Copy link
Contributor

@mgiota mgiota left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look like investigate plugin changes were properly copied from the initial POC to this new PR. I just left a few clarification questions.

@elasticmachine
Copy link
Contributor

elasticmachine commented Jul 16, 2024

💛 Build succeeded, but was flaky

Failed CI Steps

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
investigate 12 20 +8

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
investigate 95 134 +39

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id before after diff
investigate 4 6 +2

Page load bundle

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

id before after diff
investigate 2.8KB 13.0KB +10.2KB
Unknown metric groups

API count

id before after diff
investigate 95 134 +39

ESLint disabled line counts

id before after diff
investigate 0 1 +1

Total ESLint disabled count

id before after diff
investigate 2 3 +1

History

cc @kdelemme

@kdelemme kdelemme merged commit 4dca5f5 into elastic:main Jul 16, 2024
26 checks passed
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Jul 16, 2024
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 ci:project-deploy-observability Create an Observability project release_note:skip Skip the PR/issue when compiling release notes Team:obs-ux-management Observability Management User Experience Team v8.16.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants