[Security Solution][Threat Intelligence] - fix Cypress tests #209195
Conversation
PhilippeOberti
added
release_note:skip
|
Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations) |
💔 Build Failed
Failed CI StepsMetrics [docs]
History |
There was a problem hiding this comment.
security-engineering-productivity LGTM!
Qq @PhilippeOberti is there any reason why these tests are executed in ESS and not in serverless? Thanks! :)
|
@PhilippeOberti Given that Edit: I had a quick look at the changes that were merged to ES |
|
@elasticmachine merge upstream |
|
Starting backport for target branches: 8.x |
@MadameSheema I just have not had the time to test them in serverless... |
…#209195) ## Summary This PR fixes the few Threat Intelligence Cypress tests which started failing recently. [This PR](elastic#208990) ([commit](elastic@296c452) on `main`) which was a basic bump PR started had to skip a few Threat Intelligence Cypress tests that started failing. I tried to understand what happened but did not find the origin of the issue. The indicators table was previously showing data sorted from oldest to newest (but only on Cypress, not when running the application locally, really weird). After the commit mentioned above, the Cypress tests are now sorting the data from newest to oldest. Looking at the code, nothing mentions sorting, the `threatIntelligenceSearchStrategy` is identical between the application running locally and the Cypress tests. #### Payload | Local run | Cypress | | ------------- | ------------- | |  |  | #### Result The results are different, one sorted ascending, the other descending. | Local run | Cypress | | ------------- | ------------- | |  |  | No code changes have been done to the Threat Intelligence plugin in many months. Fetching the data is done using `useQuery` (see [here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/hooks/use_indicators.ts#L101)) and the logic to fetch the actual data is [here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/services/fetch_indicators.ts#L71). Both haven't been touched in months... Nothing in the commit mentioned above seems to give any details on why these tests just started failing. Resetting to the commit right before makes the tests pass... The solution to fix the tests was to ensure that the data_archive files had the correct timestamps, to know exactly which ones we select in the Cypress tests to test against... elastic#209050 elastic#209039 elastic#209051 Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> (cherry picked from commit 4886061)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
@janmonschke I thought about that too, but decided to not look into it more as it seems that nobody else is complaining about this... Though this seems like a breaking change to me, if it really is that ES is returning the results ordered in a different way... |
kibanamachine
added
the
backport missing
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
4 similar comments
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
11 similar comments
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
kibanamachine
removed
the
backport missing
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…#209195) ## Summary This PR fixes the few Threat Intelligence Cypress tests which started failing recently. [This PR](elastic#208990) ([commit](elastic@296c452) on `main`) which was a basic bump PR started had to skip a few Threat Intelligence Cypress tests that started failing. I tried to understand what happened but did not find the origin of the issue. The indicators table was previously showing data sorted from oldest to newest (but only on Cypress, not when running the application locally, really weird). After the commit mentioned above, the Cypress tests are now sorting the data from newest to oldest. Looking at the code, nothing mentions sorting, the `threatIntelligenceSearchStrategy` is identical between the application running locally and the Cypress tests. #### Payload | Local run | Cypress | | ------------- | ------------- | |  |  | #### Result The results are different, one sorted ascending, the other descending. | Local run | Cypress | | ------------- | ------------- | |  |  | No code changes have been done to the Threat Intelligence plugin in many months. Fetching the data is done using `useQuery` (see [here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/hooks/use_indicators.ts#L101)) and the logic to fetch the actual data is [here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/services/fetch_indicators.ts#L71). Both haven't been touched in months... Nothing in the commit mentioned above seems to give any details on why these tests just started failing. Resetting to the commit right before makes the tests pass... The solution to fix the tests was to ensure that the data_archive files had the correct timestamps, to know exactly which ones we select in the Cypress tests to test against... elastic#209050 elastic#209039 elastic#209051 Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> (cherry picked from commit 4886061) # Conflicts: # x-pack/test/security_solution_cypress/cypress/e2e/investigations/threat_intelligence/cases.cy.ts
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…#209195) ## Summary This PR fixes the few Threat Intelligence Cypress tests which started failing recently. [This PR](elastic#208990) ([commit](elastic@296c452) on `main`) which was a basic bump PR started had to skip a few Threat Intelligence Cypress tests that started failing. I tried to understand what happened but did not find the origin of the issue. The indicators table was previously showing data sorted from oldest to newest (but only on Cypress, not when running the application locally, really weird). After the commit mentioned above, the Cypress tests are now sorting the data from newest to oldest. Looking at the code, nothing mentions sorting, the `threatIntelligenceSearchStrategy` is identical between the application running locally and the Cypress tests. #### Payload | Local run | Cypress | | ------------- | ------------- | |  |  | #### Result The results are different, one sorted ascending, the other descending. | Local run | Cypress | | ------------- | ------------- | |  |  | No code changes have been done to the Threat Intelligence plugin in many months. Fetching the data is done using `useQuery` (see [here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/hooks/use_indicators.ts#L101)) and the logic to fetch the actual data is [here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/services/fetch_indicators.ts#L71). Both haven't been touched in months... Nothing in the commit mentioned above seems to give any details on why these tests just started failing. Resetting to the commit right before makes the tests pass... The solution to fix the tests was to ensure that the data_archive files had the correct timestamps, to know exactly which ones we select in the Cypress tests to test against... elastic#209050 elastic#209039 elastic#209051 Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> (cherry picked from commit 4886061)
…209195) (#213471) # Backport This will backport the following commits from `main` to `9.0`: - [[Security Solution][Threat Intelligence] - fix Cypress tests (#209195)](#209195) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Philippe Oberti","email":"philippe.oberti@elastic.co"},"sourceCommit":{"committedDate":"2025-02-03T15:03:32Z","message":"[Security Solution][Threat Intelligence] - fix Cypress tests (#209195)\n\n## Summary\r\n\r\nThis PR fixes the few Threat Intelligence Cypress tests which started\r\nfailing recently.\r\n\r\n[This PR](https://github.com/elastic/kibana/pull/208990)\r\n([commit](https://github.com/elastic/kibana/commit/296c452345a568c5b3dc4c39af57acd652a95f35)\r\non `main`) which was a basic bump PR started had to skip a few Threat\r\nIntelligence Cypress tests that started failing.\r\n\r\nI tried to understand what happened but did not find the origin of the\r\nissue. The indicators table was previously showing data sorted from\r\noldest to newest (but only on Cypress, not when running the application\r\nlocally, really weird). After the commit mentioned above, the Cypress\r\ntests are now sorting the data from newest to oldest.\r\nLooking at the code, nothing mentions sorting, the\r\n`threatIntelligenceSearchStrategy` is identical between the application\r\nrunning locally and the Cypress tests.\r\n\r\n#### Payload\r\n\r\n| Local run | Cypress |\r\n| ------------- | ------------- |\r\n| \r\n| \r\n|\r\n\r\n#### Result\r\n\r\nThe results are different, one sorted ascending, the other descending.\r\n\r\n| Local run | Cypress |\r\n| ------------- | ------------- |\r\n| \r\n| \r\n|\r\n\r\nNo code changes have been done to the Threat Intelligence plugin in many\r\nmonths. Fetching the data is done using `useQuery` (see\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/hooks/use_indicators.ts#L101))\r\nand the logic to fetch the actual data is\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/services/fetch_indicators.ts#L71).\r\nBoth haven't been touched in months...\r\n\r\nNothing in the commit mentioned above seems to give any details on why\r\nthese tests just started failing. Resetting to the commit right before\r\nmakes the tests pass...\r\n\r\nThe solution to fix the tests was to ensure that the data_archive files\r\nhad the correct timestamps, to know exactly which ones we select in the\r\nCypress tests to test against...\r\n\r\nhttps://github.com//issues/209050\r\nhttps://github.com//issues/209039\r\nhttps://github.com//issues/209051\r\n\r\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"48860619505c366b67ffd2028865e515878346cb","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","backport:skip","Team:Threat Hunting:Investigations","backport:version","v9.1.0"],"title":"[Security Solution][Threat Intelligence] - fix Cypress tests","number":209195,"url":"https://github.com/elastic/kibana/pull/209195","mergeCommit":{"message":"[Security Solution][Threat Intelligence] - fix Cypress tests (#209195)\n\n## Summary\r\n\r\nThis PR fixes the few Threat Intelligence Cypress tests which started\r\nfailing recently.\r\n\r\n[This PR](https://github.com/elastic/kibana/pull/208990)\r\n([commit](https://github.com/elastic/kibana/commit/296c452345a568c5b3dc4c39af57acd652a95f35)\r\non `main`) which was a basic bump PR started had to skip a few Threat\r\nIntelligence Cypress tests that started failing.\r\n\r\nI tried to understand what happened but did not find the origin of the\r\nissue. The indicators table was previously showing data sorted from\r\noldest to newest (but only on Cypress, not when running the application\r\nlocally, really weird). After the commit mentioned above, the Cypress\r\ntests are now sorting the data from newest to oldest.\r\nLooking at the code, nothing mentions sorting, the\r\n`threatIntelligenceSearchStrategy` is identical between the application\r\nrunning locally and the Cypress tests.\r\n\r\n#### Payload\r\n\r\n| Local run | Cypress |\r\n| ------------- | ------------- |\r\n| \r\n| \r\n|\r\n\r\n#### Result\r\n\r\nThe results are different, one sorted ascending, the other descending.\r\n\r\n| Local run | Cypress |\r\n| ------------- | ------------- |\r\n| \r\n| \r\n|\r\n\r\nNo code changes have been done to the Threat Intelligence plugin in many\r\nmonths. Fetching the data is done using `useQuery` (see\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/hooks/use_indicators.ts#L101))\r\nand the logic to fetch the actual data is\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/services/fetch_indicators.ts#L71).\r\nBoth haven't been touched in months...\r\n\r\nNothing in the commit mentioned above seems to give any details on why\r\nthese tests just started failing. Resetting to the commit right before\r\nmakes the tests pass...\r\n\r\nThe solution to fix the tests was to ensure that the data_archive files\r\nhad the correct timestamps, to know exactly which ones we select in the\r\nCypress tests to test against...\r\n\r\nhttps://github.com//issues/209050\r\nhttps://github.com//issues/209039\r\nhttps://github.com//issues/209051\r\n\r\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"48860619505c366b67ffd2028865e515878346cb"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/209195","number":209195,"mergeCommit":{"message":"[Security Solution][Threat Intelligence] - fix Cypress tests (#209195)\n\n## Summary\r\n\r\nThis PR fixes the few Threat Intelligence Cypress tests which started\r\nfailing recently.\r\n\r\n[This PR](https://github.com/elastic/kibana/pull/208990)\r\n([commit](https://github.com/elastic/kibana/commit/296c452345a568c5b3dc4c39af57acd652a95f35)\r\non `main`) which was a basic bump PR started had to skip a few Threat\r\nIntelligence Cypress tests that started failing.\r\n\r\nI tried to understand what happened but did not find the origin of the\r\nissue. The indicators table was previously showing data sorted from\r\noldest to newest (but only on Cypress, not when running the application\r\nlocally, really weird). After the commit mentioned above, the Cypress\r\ntests are now sorting the data from newest to oldest.\r\nLooking at the code, nothing mentions sorting, the\r\n`threatIntelligenceSearchStrategy` is identical between the application\r\nrunning locally and the Cypress tests.\r\n\r\n#### Payload\r\n\r\n| Local run | Cypress |\r\n| ------------- | ------------- |\r\n| \r\n| \r\n|\r\n\r\n#### Result\r\n\r\nThe results are different, one sorted ascending, the other descending.\r\n\r\n| Local run | Cypress |\r\n| ------------- | ------------- |\r\n| \r\n| \r\n|\r\n\r\nNo code changes have been done to the Threat Intelligence plugin in many\r\nmonths. Fetching the data is done using `useQuery` (see\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/hooks/use_indicators.ts#L101))\r\nand the logic to fetch the actual data is\r\n[here](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/threat_intelligence/public/modules/indicators/services/fetch_indicators.ts#L71).\r\nBoth haven't been touched in months...\r\n\r\nNothing in the commit mentioned above seems to give any details on why\r\nthese tests just started failing. Resetting to the commit right before\r\nmakes the tests pass...\r\n\r\nThe solution to fix the tests was to ensure that the data_archive files\r\nhad the correct timestamps, to know exactly which ones we select in the\r\nCypress tests to test against...\r\n\r\nhttps://github.com//issues/209050\r\nhttps://github.com//issues/209039\r\nhttps://github.com//issues/209051\r\n\r\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"48860619505c366b67ffd2028865e515878346cb"}}]}] BACKPORT-->
Summary
This PR fixes the few Threat Intelligence Cypress tests which started failing recently.
This PR (commit on
main) which was a basic bump PR started had to skip a few Threat Intelligence Cypress tests that started failing.I tried to understand what happened but did not find the origin of the issue. The indicators table was previously showing data sorted from oldest to newest (but only on Cypress, not when running the application locally, really weird). After the commit mentioned above, the Cypress tests are now sorting the data from newest to oldest.
Looking at the code, nothing mentions sorting, the
threatIntelligenceSearchStrategyis identical between the application running locally and the Cypress tests.Payload
Result
The results are different, one sorted ascending, the other descending.
No code changes have been done to the Threat Intelligence plugin in many months. Fetching the data is done using
useQuery(see here) and the logic to fetch the actual data is here. Both haven't been touched in months...Nothing in the commit mentioned above seems to give any details on why these tests just started failing. Resetting to the commit right before makes the tests pass...
The solution to fix the tests was to ensure that the data_archive files had the correct timestamps, to know exactly which ones we select in the Cypress tests to test against...
#209050
#209039
#209051