The cloud_security_posture integration has three policy templates, and the plugin runs an useEffect function when it is loaded to set the values of deployment and posture_type fields based on the policy template selected.
We detected that in some cases, the Form state was being reset to the initial state after the data was set by the useEffect, but that doesn't trigger a re-render, so the Form remains in an error state.
The issue can be reproduced by activating a slow network or going back and forth to the integration page multiple times.
In the video, we can see that the useEffect is called whenever Package Policy is updated unless for the case where there's a pending request that resets the state when it resolves:
Note: this integration is using the package-policy-replace-define-step extension view, which was recently introduced, but the issue happens even when changing it to package-policy-create :
We suspect It's a Race Condition bug, as stated here, happening in combination with the Suspense and useEffect. And this quote describes what's happening:
Requests from the previous profiles may sometimes “come back” after we’ve already switched the profile to another ID — and in that case, they can overwrite the new state with a stale response for a different ID.
This problem is possible to fix (you could use the effect cleanup function to either ignore or cancel stale requests), but it’s unintuitive and difficult to debug.
Steps to reproduce:
Option 1
Go to the integrations page
Click CSPM integration
Open browser dev tools and, on the network tab, enable network throttling (Fast/Slow 3G)
Click Add integration and check that a request that gets the integration data is pending, and when it responds after the useEffect runs, it will reset the form to the invalid state.
Option 2
Go to the integrations page
Click CSPM integration
Click Add integration (don't save)
Go back to the integrations page
Click KSPM integration
Click add KSPM integration (don't save)
Might be needed to repeat the operation depending on the internet speed.
Expected behavior:
Are the multiple requests needed? Can they be cached instead?
docs suggest a cleanup function can be added to cancel stale requests, however, I'm not familiar enough with the fleet plugin to know if that's applicable
Kibana version:
8.7 and 8.8
Describe the bug:
The cloud_security_posture integration has three policy templates, and the plugin runs an
useEffect
function when it is loaded to set the values of deployment and posture_type fields based on the policy template selected.We detected that in some cases, the Form state was being reset to the initial state after the data was set by the
useEffect
, but that doesn't trigger a re-render, so the Form remains in an error state.The issue can be reproduced by activating a slow network or going back and forth to the integration page multiple times.
In the video, we can see that the useEffect is called whenever Package Policy is updated unless for the case where there's a pending request that resets the state when it resolves:
https://user-images.githubusercontent.com/19270322/225731218-c6c211f3-821c-4862-8cca-d49dce27ddac.mov
Note: this integration is using the
package-policy-replace-define-step
extension view, which was recently introduced, but the issue happens even when changing it topackage-policy-create
:https://user-images.githubusercontent.com/19270322/225790090-e6d2b718-8189-4747-81b5-417fb302004e.mov
We suspect It's a Race Condition bug, as stated here, happening in combination with the
Suspense
anduseEffect
. And this quote describes what's happening:Steps to reproduce: Option 1
Option 2
Might be needed to repeat the operation depending on the internet speed.
Expected behavior: