Fix concurrent group access to prevent NullPointerException

[zaibkhan]

No description provided.

[codoki-pr-intelligence]

Codoki PR Review

Summary: Guard subgroup access under concurrency, prevent NPEs
What’s good: Fix in GroupAdapter.getSubGroupsCount() defensively handles concurrent deletion by null-checking modelSupplier.get(), reducing NPE risk.
Review Status: ❌ Requires changes
Overall Priority: High

Issues (Critical & High only)

Severity	Issue	Why it matters
High	Correctness — Potential NPE in getSubGroupsStream() under concurrent de...	…/infinispan/GroupAdapter.java Concurrent deletion can make modelSupplier.get() return null, leading to a NullPointerException here. Align the defensive pattern with getSubGroupsCount() and return an empty stream when the model is gone. Apply the same guard to the other getSubGroupsStream(...) overloads to fully harden subgroup access under concurrent modifications.

Showing top 1 issues. Critical: 0, High: 1. See inline suggestions for more.

Key Feedback (click to expand)

• Needs improvement: Similar null-guarding is still missing from getSubGroupsStream(...) overloads, which can still throw in the same concurrent deletion scenario.
• Testing: The new test spawns a reader thread without tracking or joining it, which can leak across tests and cause flakiness; also the tight while-loop busy-spins. Capture the thread and join after deletion, and add a small backoff (Thread.onSpinWait or sleep) inside the loop.
• Documentation: Document that GroupModel.getSubGroupsCount() may return null under concurrent modifications so API consumers handle this safely.
• Compatibility: Removal of groupMatchesSearchOrIsPathElement appears private-scoped; no external API break expected.
• Performance: The test's reader thread tight loop can consume significant CPU; add a small backoff.
• Open questions: Should subGroupCount being null be treated as 'unknown' or coerced to 0 in API responses? If 'unknown', confirm that serialization and consumers tolerate null.

Confidence: 3/5 — Needs work before merge (1 high · status: Requires changes)

React with 👍 or 👎 if you found this review useful.

[codoki-pr-intelligence]

🔷 Medium: The spawned reader thread is not tracked or joined, which can leak past test completion and cause flakiness; the tight while-loop also busy-spins. Capture a Thread reference, join it after setting deletedAll to true, and add a small backoff to reduce CPU usage.

Suggested change

	while (!deletedAll.get()) {
	managedRealm.admin().groups().groups(null, 0, Integer.MAX_VALUE, true); Thread.onSpinWait();