[Security Solution][Endpoint] Consistent pending actions agent status label

[ashokaditya]

Summary

Fixes the bug where users see an isolated badge for a few seconds after the host is released until it disappears.

Additionally, while testing found and fixed a bug that shows a count of pending actions when there are no pending actions. This happens due to the default query result size of 10.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/security-onboarding-and-lifecycle-mgt (Team:Onboarding and Lifecycle Mgt)

[pzl]

if it works, it works

[ashokaditya]

if it works, it works

Indeed, I tested it manually several many times to make sure it works.

[paul-tavares]

I'm having a hard time understanding why we need to useRef which given you a non-mutable const. Looking at this logic, it seem that these two variables are set only once - when the component renders for the very first time, and then they are never updated again. If that is truly what you mean with this change, then using useState() like this would do the trick:

Suggested change

	const wasReleasing = useRef<boolean>(false);
	const wasIsolating = useRef<boolean>(false);
	const [wasReleasing] = useState<boolean>(pendingIsolate === 0 && pendingUnIsolate > 0);
	const [wasIsolating] = useState<boolean>(pendingIsolate > 0 && pendingUnIsolate === 0);

but I have to ask: is that really what you expect? that these will never be updated even if the component is called with different props?

Also - since the entire returned value is already memoized, you might just want to move this logic inside of the useMemo()'s factory callback as:

const wasReleasing = pendingIsolate === 0 && pendingUnIsolate > 0;
const wasIsolating = pendingIsolate > 0 && pendingUnIsolate === 0;

---

NOTE: the reason I always pay closer attention when using useRef is that it can get you in trouble. Example: see my comment below for usage in useMemo dependencies

[ashokaditya]

Actually, useRef returns a mutable object. Since, the component re-renders anyway when pendingIsolate and pendingUnIsolate change, passing the dependency array will have the same "effect".

Overall, the idea is when the component starts to render(before returning display nodes), we want to use the old state of these values (old isolated badge) to decide which badge to show next. The endpoint metadata doesn't update the Endpoint.state.isolation value as fast as the action response indices update the pending actions count.

[paul-tavares]

Right. And since you only want it to be set on first render, you don't really need a mutable object. You can just use a useState() with an initial value right (like the suggestion in my prior comment)?

I'm approving since the end result I think is the same and you and confirmed that you truly only want this value to be capture on the very first render and even if they differ in subsequent re-renders, they will not be seen.

[ashokaditya]

@elasticmachine merge upstream

[paul-tavares]

Thanks for the responses.

🚢

[ashokaditya]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 0562eab
• Storybooks Preview

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	4.5MB	4.5MB	+215.0B

History

• 💚 Build #6808 succeeded 6058831
• 💚 Build #6565 succeeded b015338
• 💚 Build #6318 succeeded 4f17df9
• 💚 Build #6189 succeeded 3389b0c
• 💚 Build #6103 succeeded cf632cb
• 💚 Build #5046 succeeded 41687fb

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @ashokaditya

[kibanamachine]

💚 Backport successful

Status	Branch	Result
✅	8.0
✅	7.16

The backport PRs will be merged automatically after passing CI.