NHibernate query with FetchMany returns incorrect results - nhibernate

Question

I have two related entities: Job and Group, with a Many-To-Many relationship.
I am performing a simple query to retrieve a specific Job and it's associated Group (through the GroupRecipients property):
var job = jobsRepo.Get()
.Where(j => j.Id == jobKey.Id)
.FirstOrDefault();
var countA = job.GroupRecipients.Count;
The result of which is countA==2, which corresponds to the state in the database.
The first weirdness occurs when I add a FetchMany:
var job = jobsRepo.Get()
.FetchMany(x => x.GroupRecipients)
.Where(j => j.Id == jobKey.Id)
.FirstOrDefault();
var countB = job.GroupRecipients.Count;
This results in countB==1. Only one item appears in the job.GroupRecipients collection, which contradicts the state in the database.
But it get's even more interesting. If I run the following in succession:
var job = jobsRepo.Get()
.Where(j => j.Id == jobKey.Id)
.FirstOrDefault();
var countA = job.GroupRecipients.Count;
var jobB = jobsRepo.Get()
.FetchMany(x => x.GroupRecipients)
.Where(j => j.Id == jobKey.Id)
.FirstOrDefault();
var countB = jobB.GroupRecipients.Count;
Then I get countB==2, the expected result. Removing the line with countA again causes countB==1.
Some more info:
I perform the queries in a transaction in a stateless session.
The version of NHibernate is 3.3.1
The two issues can thus be summarized as following:
FetchMany returns partial results
One query is dependent on another query in an unexpected way.
Any explanation of this behavior is very welcome.

Answer 1

This appears to be a bug or mismatch in the way the LINQ provider handles FirstOrDefault - on mine, it appears to add a blanket LIMIT 1 to the query, which obviously doesn't work with the eager loading (which results in an OUTER JOIN).
I've solved it by explicitly converting to an enumerable in the middle:
var job = jobsRepo.Get()
.FetchMany(x => x.GroupRecipients)
.AsEnumerable()
.FirstOrDefault(j => j.Id == jobKey.Id);
Which is a bit of a hack, but solves the problem.
Likely, your second example works because the first loads the entity into the cache, and so nHibernate doesn't feel the need to go to the database (and encounter the faulty logic in the LINQ provider).