Thank you for the contribution. 🙏
Could you address these review findings?

Verdict: One half is a correct fix, the other half is a no-op. Request changes (or split).

Findings:

1. getTreeNodeDescendants (node?.type) - correct and relevant. This is the real fix for the reported "Cannot read properties of undefined (reading 'type')". getRowGroupChildren is public pro/premium API; applySorting is undefined by default, so the default path hits the else branch that calls getTreeNodeDescendants directly (useGridRows.ts:397). A stale/invalid groupId makes tree[parentId] undefined and crashes on node.type. The sibling applySorting branch already guards with if (!groupNode) return [] (useGridRows.ts:375), so this change just aligns the two paths. Good.

2. getTopLevelRowCount (rootGroupNode?.footerId) - ineffective, does not fix anything. On the same line, rootGroupNode.children.length is dereferenced WITHOUT optional chaining and is evaluated first (left-to-right), so if rootGroupNode is undefined it throws "Cannot read properties of undefined (reading 'children')" before ?.footerId ever runs. The ?. is dead code. It also guards children/footerId, not .type, so it is unrelated to the reported error. The root group node is built by buildRootGroup and is effectively always present, so the real-world risk here is near-zero. Recommendation: drop this hunk (preferred), or guard properly, e.g. early-return when !rootGroupNode.

Test coverage: Yes, for the effective half. Add a regression test in packages/x-data-grid-premium/src/tests/rowGroupingApiRef.DataGridPremium.test.tsx asserting getRowGroupChildren({ groupId: }) returns [] (and the same with applySorting: true for symmetry). Cheap, documents the contract, prevents regression. The getTopLevelRowCount hunk cannot be meaningfully tested because it still throws - which is itself the signal it should be removed or fixed.

LGTM, thanks for addressing this. 🙏

Could you please run prettier and commit changes?