[SecuritySolution] Make last conversation local storage keys space aware#214794
[SecuritySolution] Make last conversation local storage keys space aware#214794angorayc merged 23 commits intoelastic:mainfrom
Conversation
| inferenceEnabled={inferenceEnabled} | ||
| navigateToApp={navigateToApp} | ||
| productDocBase={productDocBase} | ||
| spaceId={spaceId ?? 'default'} |
There was a problem hiding this comment.
This might be going to use for reading the local storage keys. In other words, the spaceId cannot be null, undefined, or a fallback value when accessing it. So I moved it here x-pack/solutions/security/plugins/security_solution/public/assistant/overlay.tsx
to make sure we get space id in ElasticAssistantOverlay correctly.
| async ({ | ||
| cId, | ||
| isStreamRefetch = false, | ||
| silent, |
There was a problem hiding this comment.
I think we should only silence the error when the id comes from the lastConversation, so down in the useEffect on L256
There was a problem hiding this comment.
Also, if you're doing the space aware local storage keys, maybe we don't need to silence the error at all?
There was a problem hiding this comment.
Yeah, you are right.
I wasn't sure if I wanted to make local storage keys space aware in this PR, as wasn't sure how big the scope were 😅
After having another look, I move the last conversation relevant keys to a separate hook, looks alright so far.
To make the scope smaller, I am only making the last conversation local storage keys space aware.
There was a problem hiding this comment.
@stephmilovic I still snooze the error when conversation not found after make the local storage space aware. As I found if I created some conversations, and restart my ES. The not found error would show up.
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
History
|
stephmilovic
left a comment
There was a problem hiding this comment.
LGTM, thanks for the improvement! It might be too late to backport to 8.18. Make sure you have the 8.19 label on here too!
|
Starting backport for target branches: 8.18, 8.x, 9.0 https://github.com/elastic/kibana/actions/runs/14088634830 |
|
Starting backport for target branches: 8.18, 8.x, 9.0 https://github.com/elastic/kibana/actions/runs/14088643235 |
…are (elastic#214794) ## Summary Issue and steps to reproduce: elastic#214114 https://github.com/user-attachments/assets/881fb082-a879-4816-b251-da3f2af77661 The best approach to fix this is to make local storage keys space aware. In this use case, the current key is `elasticAssistantDefault.lastSelectedConversation`. Ideally it should be e.g.: `elasticAssistantDefault.lastSelectedConversation.{spaceId}` To retrieve spaceId properly, we have to make sure spaceId has been available when reading the local storage. In other words, the spaceId cannot be null, undefined, or a fallback value when accessing it. To achieve that, we have to only render the assistant overlay after spaceId is available and remove existing spaceId from the AssistantContext. The reason I removed spaceId from AssistantContext is because it is at the top of the rendering tree and can block the entire app if waiting for the spaceId becomes available there. `useAssistantSpaceId` comes from `SpaceIdContext` which should be render only when spaceId is available, should be safe to access the exact spaceId inside Assistant overly. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 169abec)
💔 Some backports could not be created
Note: Successful backport PRs will be merged automatically after passing CI. Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
…are (elastic#214794) ## Summary Issue and steps to reproduce: elastic#214114 https://github.com/user-attachments/assets/881fb082-a879-4816-b251-da3f2af77661 The best approach to fix this is to make local storage keys space aware. In this use case, the current key is `elasticAssistantDefault.lastSelectedConversation`. Ideally it should be e.g.: `elasticAssistantDefault.lastSelectedConversation.{spaceId}` To retrieve spaceId properly, we have to make sure spaceId has been available when reading the local storage. In other words, the spaceId cannot be null, undefined, or a fallback value when accessing it. To achieve that, we have to only render the assistant overlay after spaceId is available and remove existing spaceId from the AssistantContext. The reason I removed spaceId from AssistantContext is because it is at the top of the rendering tree and can block the entire app if waiting for the spaceId becomes available there. `useAssistantSpaceId` comes from `SpaceIdContext` which should be render only when spaceId is available, should be safe to access the exact spaceId inside Assistant overly. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 169abec)
💔 Some backports could not be created
Note: Successful backport PRs will be merged automatically after passing CI. Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
…ace aware (#214794) (#216085) # Backport This will backport the following commits from `main` to `8.x`: - [[SecuritySolution] Make last conversation local storage keys space aware (#214794)](#214794) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Angela Chuang","email":"6295984+angorayc@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-03-26T16:34:48Z","message":"[SecuritySolution] Make last conversation local storage keys space aware (#214794)\n\n## Summary\n\nIssue and steps to reproduce:\nhttps://github.com//issues/214114\n\n\n\n\nhttps://github.com/user-attachments/assets/881fb082-a879-4816-b251-da3f2af77661\n\n\n\nThe best approach to fix this is to make local storage keys space aware.\nIn this use case, the current key is\n`elasticAssistantDefault.lastSelectedConversation`.\n\nIdeally it should be e.g.:\n`elasticAssistantDefault.lastSelectedConversation.{spaceId}`\n\nTo retrieve spaceId properly, we have to make sure spaceId has been\navailable when reading the local storage. In other words, the spaceId\ncannot be null, undefined, or a fallback value when accessing it.\n\nTo achieve that, we have to only render the assistant overlay after\nspaceId is available and remove existing spaceId from the\nAssistantContext. The reason I removed spaceId from AssistantContext is\nbecause it is at the top of the rendering tree and can block the entire\napp if waiting for the spaceId becomes available there.\n\n`useAssistantSpaceId` comes from `SpaceIdContext` which should be render\nonly when spaceId is available, should be safe to access the exact\nspaceId inside Assistant overly.\n\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"169abecdda27d834dfd417218e3dbf0102ff65a8","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","v9.0.0","Team:Security Generative AI","backport:version","v9.1.0","v8.19.0","v8.18.1"],"title":"[SecuritySolution] Make last conversation local storage keys space aware","number":214794,"url":"https://github.com/elastic/kibana/pull/214794","mergeCommit":{"message":"[SecuritySolution] Make last conversation local storage keys space aware (#214794)\n\n## Summary\n\nIssue and steps to reproduce:\nhttps://github.com//issues/214114\n\n\n\n\nhttps://github.com/user-attachments/assets/881fb082-a879-4816-b251-da3f2af77661\n\n\n\nThe best approach to fix this is to make local storage keys space aware.\nIn this use case, the current key is\n`elasticAssistantDefault.lastSelectedConversation`.\n\nIdeally it should be e.g.:\n`elasticAssistantDefault.lastSelectedConversation.{spaceId}`\n\nTo retrieve spaceId properly, we have to make sure spaceId has been\navailable when reading the local storage. In other words, the spaceId\ncannot be null, undefined, or a fallback value when accessing it.\n\nTo achieve that, we have to only render the assistant overlay after\nspaceId is available and remove existing spaceId from the\nAssistantContext. The reason I removed spaceId from AssistantContext is\nbecause it is at the top of the rendering tree and can block the entire\napp if waiting for the spaceId becomes available there.\n\n`useAssistantSpaceId` comes from `SpaceIdContext` which should be render\nonly when spaceId is available, should be safe to access the exact\nspaceId inside Assistant overly.\n\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"169abecdda27d834dfd417218e3dbf0102ff65a8"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.x","8.18"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/214794","number":214794,"mergeCommit":{"message":"[SecuritySolution] Make last conversation local storage keys space aware (#214794)\n\n## Summary\n\nIssue and steps to reproduce:\nhttps://github.com//issues/214114\n\n\n\n\nhttps://github.com/user-attachments/assets/881fb082-a879-4816-b251-da3f2af77661\n\n\n\nThe best approach to fix this is to make local storage keys space aware.\nIn this use case, the current key is\n`elasticAssistantDefault.lastSelectedConversation`.\n\nIdeally it should be e.g.:\n`elasticAssistantDefault.lastSelectedConversation.{spaceId}`\n\nTo retrieve spaceId properly, we have to make sure spaceId has been\navailable when reading the local storage. In other words, the spaceId\ncannot be null, undefined, or a fallback value when accessing it.\n\nTo achieve that, we have to only render the assistant overlay after\nspaceId is available and remove existing spaceId from the\nAssistantContext. The reason I removed spaceId from AssistantContext is\nbecause it is at the top of the rendering tree and can block the entire\napp if waiting for the spaceId becomes available there.\n\n`useAssistantSpaceId` comes from `SpaceIdContext` which should be render\nonly when spaceId is available, should be safe to access the exact\nspaceId inside Assistant overly.\n\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"169abecdda27d834dfd417218e3dbf0102ff65a8"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.18","label":"v8.18.1","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Angela Chuang <6295984+angorayc@users.noreply.github.com>
…are (elastic#214794) Issue and steps to reproduce: elastic#214114 https://github.com/user-attachments/assets/881fb082-a879-4816-b251-da3f2af77661 The best approach to fix this is to make local storage keys space aware. In this use case, the current key is `elasticAssistantDefault.lastSelectedConversation`. Ideally it should be e.g.: `elasticAssistantDefault.lastSelectedConversation.{spaceId}` To retrieve spaceId properly, we have to make sure spaceId has been available when reading the local storage. In other words, the spaceId cannot be null, undefined, or a fallback value when accessing it. To achieve that, we have to only render the assistant overlay after spaceId is available and remove existing spaceId from the AssistantContext. The reason I removed spaceId from AssistantContext is because it is at the top of the rendering tree and can block the entire app if waiting for the spaceId becomes available there. `useAssistantSpaceId` comes from `SpaceIdContext` which should be render only when spaceId is available, should be safe to access the exact spaceId inside Assistant overly. Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 169abec)
…ace aware (#214794) (#216214) # Backport This will backport the following commits from `main` to `9.0`: - [[SecuritySolution] Make last conversation local storage keys space aware (#214794)](#214794) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
…are (elastic#214794) ## Summary Issue and steps to reproduce: elastic#214114 https://github.com/user-attachments/assets/881fb082-a879-4816-b251-da3f2af77661 The best approach to fix this is to make local storage keys space aware. In this use case, the current key is `elasticAssistantDefault.lastSelectedConversation`. Ideally it should be e.g.: `elasticAssistantDefault.lastSelectedConversation.{spaceId}` To retrieve spaceId properly, we have to make sure spaceId has been available when reading the local storage. In other words, the spaceId cannot be null, undefined, or a fallback value when accessing it. To achieve that, we have to only render the assistant overlay after spaceId is available and remove existing spaceId from the AssistantContext. The reason I removed spaceId from AssistantContext is because it is at the top of the rendering tree and can block the entire app if waiting for the spaceId becomes available there. `useAssistantSpaceId` comes from `SpaceIdContext` which should be render only when spaceId is available, should be safe to access the exact spaceId inside Assistant overly. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Summary
Issue and steps to reproduce:
#214114
Screen.Recording.2025-03-18.at.14.52.12.mov
The best approach to fix this is to make local storage keys space aware. In this use case, the current key is
elasticAssistantDefault.lastSelectedConversation.Ideally it should be e.g.:
elasticAssistantDefault.lastSelectedConversation.{spaceId}To retrieve spaceId properly, we have to make sure spaceId has been available when reading the local storage. In other words, the spaceId cannot be null, undefined, or a fallback value when accessing it.
To achieve that, we have to only render the assistant overlay after spaceId is available and remove existing spaceId from the AssistantContext. The reason I removed spaceId from AssistantContext is because it is at the top of the rendering tree and can block the entire app if waiting for the spaceId becomes available there.
useAssistantSpaceIdcomes fromSpaceIdContextwhich should be render only when spaceId is available, should be safe to access the exact spaceId inside Assistant overly.Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.