Skip to content

[React18] Migrate test suites to account for testing library upgrades security-threat-hunting-investigations#201145

Merged
eokoneyo merged 1 commit intomainfrom
chore/testing-library-migration-for-security-threat-hunting-investigations
Nov 22, 2024
Merged

[React18] Migrate test suites to account for testing library upgrades security-threat-hunting-investigations#201145
eokoneyo merged 1 commit intomainfrom
chore/testing-library-migration-for-security-threat-hunting-investigations

Conversation

@eokoneyo
Copy link
Copy Markdown
Contributor

@eokoneyo eokoneyo commented Nov 21, 2024 •
edited by kibanamachine
Loading

This PR migrates test suites that use renderHook from the library @testing-library/react-hooks to adopt the equivalent and replacement of renderHook from the export that is now available from
@testing-library/react. This work is required for the planned migration to react18.

Context

In this PR, usages of waitForNextUpdate that previously could have been destructured from renderHook are now been replaced with waitFor exported from @testing-library/react, furthermore waitFor
that would also have been destructured from the same renderHook result is now been replaced with waitFor from the export of @testing-library/react.

Why is waitFor a sufficient enough replacement for waitForNextUpdate, and better for testing values subject to async computations?

WaitFor will retry the provided callback if an error is returned, till the configured timeout elapses. By default the retry interval is 50ms with a timeout value of 1000ms that
effectively translates to at least 20 retries for assertions placed within waitFor. See https://testing-library.com/docs/dom-testing-library/api-async/#waitfor for more information.
This however means that for person's writing tests, said person has to be explicit about expectations that describe the internal state of the hook being tested.
This implies checking for instance when a react query hook is being rendered, there's an assertion that said hook isn't loading anymore.

In this PR you'd notice that this pattern has been adopted, with most existing assertions following an invocation of waitForNextUpdate being placed within a waitFor
invocation. In some cases the replacement is simply a waitFor(() => new Promise((resolve) => resolve(null))) (many thanks to @kapral18, for point out exactly why this works),
where this suffices the assertions that follow aren't placed within a waitFor so this PR doesn't get larger than it needs to be.

It's also worth pointing out this PR might also contain changes to test and application code to improve said existing test.

What to do next?

  1. Review the changes in this PR.
  2. If you think the changes are correct, approve the PR.

Any questions?

If you have any questions or need help with this PR, please leave comments in this PR.

@eokoneyo eokoneyo added release_note:skip Skip the PR/issue when compiling release notes Team:Threat Hunting:Investigations Security Solution Threat Hunting Investigations Team backport:prev-minor React@18 labels Nov 21, 2024
@eokoneyo eokoneyo self-assigned this Nov 21, 2024
@eokoneyo
Copy link
Copy Markdown
Contributor Author

eokoneyo commented Nov 21, 2024

/ci

@eokoneyo eokoneyo marked this pull request as ready for review November 21, 2024 17:18
@eokoneyo eokoneyo requested a review from a team as a code owner November 21, 2024 17:18
@elasticmachine
Copy link
Copy Markdown
Contributor

elasticmachine commented Nov 21, 2024

Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations)

PhilippeOberti
PhilippeOberti approved these changes Nov 21, 2024
View reviewed changes
Copy link
Copy Markdown
Contributor

@PhilippeOberti PhilippeOberti 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 making these changes @eokoneyo, LGTM! I left one question if you don't mind explaining the reasoning behind some decisions

.../public/common/components/markdown_editor/plugins/insight/use_insight_data_providers.test.ts Outdated
Copy link
Copy Markdown
Contributor

@PhilippeOberti PhilippeOberti Nov 21, 2024

Choose a reason for hiding this comment

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

just curious about why removing the types here (and in a few other files) but in most other places in this PR they are just reverted?

Copy link
Copy Markdown
Contributor Author

@eokoneyo eokoneyo Nov 21, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

just curious about why removing the types here (and in a few other files) but in most other places in this PR they are just reverted?

previously renderHook defined generics for the render result and the props for the hook in the order <Props, Result> but that was changed to be ordered as <Result, Props> since, the util itself can now infer the type for result and the accepted prop, it seemed more reasonable to remove the type altogether as opposed to switching the type definition around.

...ck/plugins/security_solution/public/sourcerer/components/use_get_sourcerer_data_view.test.ts Outdated
Copy link
Copy Markdown
Contributor

@PhilippeOberti PhilippeOberti Nov 21, 2024

Choose a reason for hiding this comment

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

same question here

Copy link
Copy Markdown
Contributor Author

@eokoneyo eokoneyo Nov 21, 2024

Choose a reason for hiding this comment

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

See #201145 (comment)

@eokoneyo
[React18] Migrated test suites to accommodate changes to testing libr…
212fe8e 
…ary owned by security-threat-hunting-investigations
@eokoneyo eokoneyo force-pushed the chore/testing-library-migration-for-security-threat-hunting-investigations branch from 021a6f4 to 212fe8e Compare November 22, 2024 09:04
@eokoneyo eokoneyo enabled auto-merge (squash) November 22, 2024 09:04
@eokoneyo eokoneyo merged commit 06de5f3 into main Nov 22, 2024
@eokoneyo eokoneyo deleted the chore/testing-library-migration-for-security-threat-hunting-investigations branch November 22, 2024 10:54
@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Nov 22, 2024

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/11971240872

@elasticmachine
Copy link
Copy Markdown
Contributor

elasticmachine commented Nov 22, 2024

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #83 / dashboard dashboard lens by value can add a lens panel by value

Metrics [docs]

✅ unchanged

History

  • 💚 Build #253194 succeeded 021a6f47a34d3f8169b9cb43561292ec73f20779

cc @eokoneyo

@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Nov 22, 2024

💔 All backports failed

Status Branch Result
❌ 8.x Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 201145

Questions ?

Please refer to the Backport tool documentation

@kibanamachine kibanamachine added the backport missing Added to PRs automatically when the are determined to be missing a backport. label Nov 25, 2024
@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Nov 25, 2024

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 201145 locally

1 similar comment
@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Nov 26, 2024

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 201145 locally

@eokoneyo eokoneyo mentioned this pull request Nov 26, 2024
Merged
@eokoneyo
Copy link
Copy Markdown
Contributor Author

eokoneyo commented Nov 26, 2024

💚 All backports created successfully

Status Branch Result
✅ 8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

paulinashakirova pushed a commit to paulinashakirova/kibana that referenced this pull request Nov 26, 2024
@eokoneyo @paulinashakirova
[React18] Migrate test suites to account for testing library upgrades…
bca86eb 
… security-threat-hunting-investigations (elastic#201145)

This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.

##  Context

In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.

***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***

WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.

In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.

It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.

### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.

## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Nov 27, 2024

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.

2 similar comments
@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Nov 28, 2024

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.

@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Nov 29, 2024

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.

@kibanamachine kibanamachine mentioned this pull request Nov 29, 2024
Merged
@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Dec 2, 2024

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.

@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Dec 3, 2024

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.

1 similar comment
@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Dec 4, 2024

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.

eokoneyo added a commit to eokoneyo/kibana that referenced this pull request Dec 5, 2024
@eokoneyo
[React18] Migrate test suites to account for testing library upgrades…
a779c61 
… security-threat-hunting-investigations (elastic#201145)

This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.

In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.

***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***

WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.

In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.

It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.

1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.

If you have any questions or need help with this PR, please leave
comments in this PR.

(cherry picked from commit 06de5f3)
@kibanamachine
Copy link
Copy Markdown
Contributor

kibanamachine commented Dec 5, 2024

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.

eokoneyo added a commit that referenced this pull request Dec 5, 2024
@eokoneyo
[8.x] [React18] Migrate test suites to account for testing library up…
62f28c4 
…grades security-threat-hunting-investigations (#201145) (#201859)

# Backport

This will backport the following commits from `main` to `8.x`:
- [[React18] Migrate test suites to account for testing library upgrades
security-threat-hunting-investigations
(#201145)](#201145)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Eyo O.
Eyo","email":"7893459+eokoneyo@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-11-22T10:54:41Z","message":"[React18]
Migrate test suites to account for testing library upgrades
security-threat-hunting-investigations (#201145)\n\nThis PR migrates
test suites that use `renderHook` from the
library\r\n`@testing-library/react-hooks` to adopt the equivalent and
replacement\r\nof `renderHook` from the export that is now available
from\r\n`@testing-library/react`. This work is required for the
planned\r\nmigration to react18.\r\n\r\n## Context\r\n\r\nIn this PR,
usages of `waitForNextUpdate` that previously could have\r\nbeen
destructured from `renderHook` are now been replaced with
`waitFor`\r\nexported from `@testing-library/react`, furthermore
`waitFor`\r\nthat would also have been destructured from the same
renderHook result\r\nis now been replaced with `waitFor` from the export
of\r\n`@testing-library/react`.\r\n\r\n***Why is `waitFor` a sufficient
enough replacement for\r\n`waitForNextUpdate`, and better for testing
values subject to async\r\ncomputations?***\r\n\r\nWaitFor will retry
the provided callback if an error is returned, till\r\nthe configured
timeout elapses. By default the retry interval is `50ms`\r\nwith a
timeout value of `1000ms` that\r\neffectively translates to at least 20
retries for assertions placed\r\nwithin waitFor.
See\r\nhttps://testing-library.com/docs/dom-testing-library/api-async/#waitfor\r\nfor
more information.\r\nThis however means that for person's writing tests,
said person has to\r\nbe explicit about expectations that describe the
internal state of the\r\nhook being tested.\r\nThis implies checking for
instance when a react query hook is being\r\nrendered, there's an
assertion that said hook isn't loading anymore.\r\n\r\nIn this PR you'd
notice that this pattern has been adopted, with most\r\nexisting
assertions following an invocation of `waitForNextUpdate`
being\r\nplaced within a `waitFor`\r\ninvocation. In some cases the
replacement is simply a `waitFor(() => new\r\nPromise((resolve) =>
resolve(null)))` (many thanks to @kapral18, for\r\npoint out exactly why
this works),\r\nwhere this suffices the assertions that follow aren't
placed within a\r\nwaitFor so this PR doesn't get larger than it needs
to be.\r\n\r\nIt's also worth pointing out this PR might also contain
changes to test\r\nand application code to improve said existing
test.\r\n\r\n### What to do next?\r\n1. Review the changes in this
PR.\r\n2. If you think the changes are correct, approve the
PR.\r\n\r\n## Any questions?\r\nIf you have any questions or need help
with this PR, please leave\r\ncomments in this
PR.","sha":"06de5f3f51961df174ae109a200a8ae1e4acfaff","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","backport
missing","v9.0.0","Team:Threat
Hunting:Investigations","backport:prev-minor","React@18"],"number":201145,"url":"https://github.com/elastic/kibana/pull/201145","mergeCommit":{"message":"[React18]
Migrate test suites to account for testing library upgrades
security-threat-hunting-investigations (#201145)\n\nThis PR migrates
test suites that use `renderHook` from the
library\r\n`@testing-library/react-hooks` to adopt the equivalent and
replacement\r\nof `renderHook` from the export that is now available
from\r\n`@testing-library/react`. This work is required for the
planned\r\nmigration to react18.\r\n\r\n## Context\r\n\r\nIn this PR,
usages of `waitForNextUpdate` that previously could have\r\nbeen
destructured from `renderHook` are now been replaced with
`waitFor`\r\nexported from `@testing-library/react`, furthermore
`waitFor`\r\nthat would also have been destructured from the same
renderHook result\r\nis now been replaced with `waitFor` from the export
of\r\n`@testing-library/react`.\r\n\r\n***Why is `waitFor` a sufficient
enough replacement for\r\n`waitForNextUpdate`, and better for testing
values subject to async\r\ncomputations?***\r\n\r\nWaitFor will retry
the provided callback if an error is returned, till\r\nthe configured
timeout elapses. By default the retry interval is `50ms`\r\nwith a
timeout value of `1000ms` that\r\neffectively translates to at least 20
retries for assertions placed\r\nwithin waitFor.
See\r\nhttps://testing-library.com/docs/dom-testing-library/api-async/#waitfor\r\nfor
more information.\r\nThis however means that for person's writing tests,
said person has to\r\nbe explicit about expectations that describe the
internal state of the\r\nhook being tested.\r\nThis implies checking for
instance when a react query hook is being\r\nrendered, there's an
assertion that said hook isn't loading anymore.\r\n\r\nIn this PR you'd
notice that this pattern has been adopted, with most\r\nexisting
assertions following an invocation of `waitForNextUpdate`
being\r\nplaced within a `waitFor`\r\ninvocation. In some cases the
replacement is simply a `waitFor(() => new\r\nPromise((resolve) =>
resolve(null)))` (many thanks to @kapral18, for\r\npoint out exactly why
this works),\r\nwhere this suffices the assertions that follow aren't
placed within a\r\nwaitFor so this PR doesn't get larger than it needs
to be.\r\n\r\nIt's also worth pointing out this PR might also contain
changes to test\r\nand application code to improve said existing
test.\r\n\r\n### What to do next?\r\n1. Review the changes in this
PR.\r\n2. If you think the changes are correct, approve the
PR.\r\n\r\n## Any questions?\r\nIf you have any questions or need help
with this PR, please leave\r\ncomments in this
PR.","sha":"06de5f3f51961df174ae109a200a8ae1e4acfaff"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201145","number":201145,"mergeCommit":{"message":"[React18]
Migrate test suites to account for testing library upgrades
security-threat-hunting-investigations (#201145)\n\nThis PR migrates
test suites that use `renderHook` from the
library\r\n`@testing-library/react-hooks` to adopt the equivalent and
replacement\r\nof `renderHook` from the export that is now available
from\r\n`@testing-library/react`. This work is required for the
planned\r\nmigration to react18.\r\n\r\n## Context\r\n\r\nIn this PR,
usages of `waitForNextUpdate` that previously could have\r\nbeen
destructured from `renderHook` are now been replaced with
`waitFor`\r\nexported from `@testing-library/react`, furthermore
`waitFor`\r\nthat would also have been destructured from the same
renderHook result\r\nis now been replaced with `waitFor` from the export
of\r\n`@testing-library/react`.\r\n\r\n***Why is `waitFor` a sufficient
enough replacement for\r\n`waitForNextUpdate`, and better for testing
values subject to async\r\ncomputations?***\r\n\r\nWaitFor will retry
the provided callback if an error is returned, till\r\nthe configured
timeout elapses. By default the retry interval is `50ms`\r\nwith a
timeout value of `1000ms` that\r\neffectively translates to at least 20
retries for assertions placed\r\nwithin waitFor.
See\r\nhttps://testing-library.com/docs/dom-testing-library/api-async/#waitfor\r\nfor
more information.\r\nThis however means that for person's writing tests,
said person has to\r\nbe explicit about expectations that describe the
internal state of the\r\nhook being tested.\r\nThis implies checking for
instance when a react query hook is being\r\nrendered, there's an
assertion that said hook isn't loading anymore.\r\n\r\nIn this PR you'd
notice that this pattern has been adopted, with most\r\nexisting
assertions following an invocation of `waitForNextUpdate`
being\r\nplaced within a `waitFor`\r\ninvocation. In some cases the
replacement is simply a `waitFor(() => new\r\nPromise((resolve) =>
resolve(null)))` (many thanks to @kapral18, for\r\npoint out exactly why
this works),\r\nwhere this suffices the assertions that follow aren't
placed within a\r\nwaitFor so this PR doesn't get larger than it needs
to be.\r\n\r\nIt's also worth pointing out this PR might also contain
changes to test\r\nand application code to improve said existing
test.\r\n\r\n### What to do next?\r\n1. Review the changes in this
PR.\r\n2. If you think the changes are correct, approve the
PR.\r\n\r\n## Any questions?\r\nIf you have any questions or need help
with this PR, please leave\r\ncomments in this
PR.","sha":"06de5f3f51961df174ae109a200a8ae1e4acfaff"}}]}] BACKPORT-->
@kibanamachine kibanamachine added v8.18.0 and removed backport missing Added to PRs automatically when the are determined to be missing a backport. labels Dec 5, 2024
CAWilson94 pushed a commit to CAWilson94/kibana that referenced this pull request Dec 12, 2024
@eokoneyo @CAWilson94
[React18] Migrate test suites to account for testing library upgrades…
8a4ae9a 
… security-threat-hunting-investigations (elastic#201145)

This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.

##  Context

In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.

***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***

WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.

In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.

It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.

### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.

## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@PhilippeOberti PhilippeOberti PhilippeOberti approved these changes

Assignees

@eokoneyo eokoneyo

Labels

React@18 release_note:skip Skip the PR/issue when compiling release notes Team:Threat Hunting:Investigations Security Solution Threat Hunting Investigations Team v8.18.0 v9.0.0

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@eokoneyo @elasticmachine @kibanamachine @PhilippeOberti