Boolean expression is assigned the incorrect value after the same code was run previously with some input

[WGroenestein]

This one is a bit of a weird reproduction which I cannot fully explain. In our code base we have some code to list the X amount of up coming birthdays. We used to use 4.0.0 in combination with MS SQL 2008 dialect and we added some additional functions for DateTime operations to be able to be converted to SQL (AddYears and DayOfYear). Recently we tried to update to the latest version (5.2.3) and we noticed that the tests we have for this provider started to fail. Running the tests individual make them all pass (so there was something flaky going on). I was able to reduced the reproduction down in a repo repro (https://github.com/WGroenestein/nhibernate-birthday-5.1.0-break) and noticed that the last version of NHibernate where the tests succeeded was 5.0.8. Since I was not a contributor I could not create an issue so Instead I've created PR #2528.

The thing here is that running List_DealsWithYearTransitionProperly and List_WorksForTomorrow in isolation works fine. However when List_DealsWithYearTransitionProperly is run prio to List_WorksForTomorrow suddenly it fails. And it appears to fail in the way the DayOfYear integer returned from SQL is converted to the .NET boolean (at least that is my understanding).

For our codebase we have introduced a work around of manual recomputing the boolean, but I though it would be good to make you guys aware of as it seems to be weird behavior

[fredericDelaporte]

Latest version is 5.3.2 (not 5.2.3) and 5.3.0 has some regressions about Linq parameter values getting unexpectedly "cached", which could be the cause of your issue, fixed in 5.3.3 (not yet released). (I have not actually checked your sample code case, it just sounds as a possible cause.) See #2519.
You may check this by testing the MyGet latest 5.3.x dev version. (The latest as of this writing is here ; 5.4.x dev versions do not have those fixes merged yet.)

[WGroenestein]

Sorry got the version mixed up indeed. I've checked my repo repro against 5.3.3-dev.3125 and it now passes, thanks for the info. Ill close this issue and the PR.