If an user (willing or by mistake) attempts to hide a container object parenting a very large tree of content objects (say 500k), the process will either fail or take for ever to execute.

Regardless of all improvements introduced in the past, in legacy, a bottleneck remains in the cache clearing process execution. Specifically in eZContentObjectTreeNode::clearViewCacheForSubtree.

The algorithm that we use here is quite simple, we grab chunks of subtree items and clearContentCacheIfNeeded them.

What happens if this subtree happens to hold 100k nodes? we execute 500 cycles of clearing clearing cache for 200 nodes.
This behaviour is already the result of an enhancement. Before 2012 we would be executing 2000 cycles (50 node limit)

An enhancement that can be introduced here is to check, before executing the cache clearing chunks, if the number of nodes in the subtree exceeds the configured ContentSettings.CacheThreshold. If it does, we skip clearing cache blocks for the individually and just expire it all.

Basically, we add the following in eZContentObjectTreeNode::clearViewCacheForSubtree :

$subtreeCount = $node->subTreeCount( $params );
if ( ! eZContentCache::inCleanupThresholdRange( $subtreeCount ) ) {
    eZDebug::writeDebug( "Expiring all view cache since list of nodes({$subtreeCount}) related to object({$objectID}) exeeds site.ini\[ContentSettings]\CacheThreshold", __METHOD__ );
    ezpEvent::getInstance()->filter( 'content/cache/all' );
    eZContentObject::expireAllViewCache();
} else {
    // proceed with the current process, selecting chunks and clearing cache for them....
    while ( $offset < $subtreeCount )
....

Afaikt, the worst thing that may result from this change is the system ending up clearing the whole cache more often, if the Threshold is misadjusted.
Am I missing a missing any other undesired effect?