I deployed on our servers a 4.1.8 version patched with HHH-7829 fixed (as it was in the way) and some additional logging in BatchFetchQueue.

After more time looking at the code, I'm wondering if the collection batch fetching patch has missed something in AbstractFlushingEventListener.postFlush().

Shouldn't we also clean up the batchLoadableCollections map from persistenceContext.getBatchFetchQueue() in AbstractFlushingEventListener.postFlush()?

Currently, only the subselectsByEntityKey map is cleaned up:

persistenceContext.getBatchFetchQueue()
				.clearSubselects(); //the database has changed now, so the subselect results need to be invalidated

and I think that considering all the collection cleanup that comes afterwards in the very same method, persistenceContext.getBatchFetchQueue().batchLoadableCollections should also be cleaned up.

The fact is that what triggered this NPE for us is a batch loading script where we do session.flush() / session.clear() every N objects.

By the way, I took a look at how CollectionEntry.loadedKey was used in the code and it seems that it might be null sometimes (see the start of CollectionEntry.preFlush):

public void preFlush(PersistentCollection collection) throws HibernateException {
		if ( loadedKey == null && collection.getKey() != null ) {
			loadedKey = collection.getKey();
		}

this condition was added by Steve in the following commit: https://github.com/hibernate/hibernate-orm/commit/183c914f5769f7072fd9ff8d5591e816dfc0c353 . I'm not convinced it's related to our problem though as we don't use JoinColumn in our application but I think it was worth mentioning that I'm not sure we can consider the loadedKey being non null. There are a couple of other tests on ce.getLoadedKey() != null in the code.

Note that it might be OK in the specific cases we send to the collection batch fetching code but it might be worth it to double check.