This is somewhat the same issue as NH-2322, which has been resolved with what I see as a crutch (switching a foreach loop for a for, in order to avoid the "collection modified during enumeration" error). But this crutch does not help for NH-4077.

In fact, the auto-flush is mainly disabled during operation which internals may triggers auto-flush, after they have already triggered it if required. The regular flush (included the one from commit) does not disable it. I am checking what it gives to have it disabled from the regular flush too.

Actually, it seems that I can force two different exceptions by doing the same thing (causing auto-flush) from different Listeners.
Doing it during a IPostUpdateEventListener causes the ArgumentOutOfRangeException, but doing the same thing from a IPostInsertEventListener leads to a primary key violation due to the same inserts running multiple times.

Test cases on my GitHub fork

Using FlushMode.Commit actually does fix both of them, as well as removing the transaction and only using the session. But since we use this for multi-layered objects that need a consistent state, dropping the transaction isn't really an option. And with FlushMode.Commit, we noticed that some query results (ie. for validations beforehand or other bookkeeping that happens afterwards) were infavorable for what we wanted to do at that point (basically amounting to a dirty read, if we think about it carefully...so something that we'll have to fix as well, one way or the other)

Well, glad you have found the root of the issue.

I tend to think that this case, having a flush triggered from a session event itself flush related, would be considered as an invalid usage case. So it would need to be fixed by user code rather than by changes in NHibernate code. Now having a test case would help to check if this is really the case. So feel free to add it there anyway.

Side note: if this trouble is triggered only by an auto-flush (flush done prior to a query which may have to touch some dirtied entities), you could check if disabling it (lowering FlushMode to Commit instead of Auto) is enough (and valid) for your case. Of course you need to analyze the consequences, such as queries taking into account only the actual state of data in database, instead of its state amended by ongoing changes in the session.
(Now thinking about it, normally auto-flushes are disabled during flushes, so we may have a bug here in NHibernate if your case is really triggered by what we call auto-flush.)

About mixing scopes and native transactions, guidances were not well defined on NHibernate side either, and are still not indeed. may amend the documentation for sorting it out.

This is on a Windows Service application self-hosting a WCF service, no IIS or ASP.Net. CreateSession is merely a custom class that does nothing else than initialize a session-factory, keep it in a static field (because creating the session-factory is usually the heavy part) and wrap calls to OpenSession:

Nothing ThreadStatic in there, or related to a ThreadContext as far as I can see.

But to be fair, that piece of code has been around for almost 10 years now and the colleague that wrote it has left the company; so I cannot really tell if he knew about not mixing them or not. It probably seemed like a-good-idea™ back then; with the intent of that method to ensure a batch of work (multiple entity inserts/updates) either fully complete atomically, or not at all. It feels a little like he adopted some code that used System.Transactions in such a pattern and simply substituted NHibernate transactions.
I just ran my sample without the TransactionScope and got the same result (ArgumentOutOfRange exception on that very spot), so I'm not entirely sure this is the fault of mixing them - but regardless, your write-up is gold, thanks for that!

After almost of day of debugging, it appears we cause an Auto-Flush on that very same session that is currently being flushed/committed inside some IPostUpdateEventListener that attempts to do some bookkeeping. As a result, ActionQueue.ClearFromFlushNeededCheck clears that list which is currently being iterated inside ActionQueue.ExecuteActions (it's even visible in the stack trace if you drill deep enough).
So apparently it is our own fault after all, and we need to fix this in our code. Infact, doing so fixes the issue.

It is probably appropriate to close this issue...unless you have reason to believe there is indeed something that could/should be done from NHibernate to prevent those misbehaviors. Sorry for taking up your time on that, since we could've invested the time to investigate this properly like a year ago already :/

I got a Test-Case that reproduces the issue; but I'll still have to clean it up a little.

We will probably not include your workaround, because this would very likely just hide the actual trouble instead of solving it.

The fact that your problem seems somewhat random looks like a threading trouble, although you assert your sessions are not shared among threads. CreateSession looks as some custom code, since the actual NHibernate method is OpenSession. Are you using some ThreadContext backed current session mechanism? If yes, within an IIS web app, Asp.Net thread agility could then cause a session to be used by a concurrent request. (Well, quite unlikely with your using pattern anyway.)

Otherwise maybe your application has added some interceptors/events triggered by those actions which would sometimes alter the session.

I am afraid you will need to achieve producing a test case for this trouble to be solved.

By the way, NHibernate transactions should not be mixed with transaction scopes, because this causes ADO transactions to be mixed with System transactions, which Microsoft advises against. See more details on (long read).