Issue with Mendix Erasing transient object much earlier in 7.20
Our application uses transient object to store duplication information before committing additional records. In 7.19 a button called a microflow which generated a transient object (hereafter alpha) with a pair of arrays of associated transient objects, and alpha was used to populate a pop-up page view while its two associated transient arrays populated a pair of list views on the same page. This has worked great up until the 7.20 release. Now, on 7.20, loading the previously mentioned pop-up causes a "Please contact your system administrator" error, as well as sending an error to the log (leading trace line: java.lang.ClassCastException: java.lang.String cannot be cast to com.mendix.thirdparty.org.json.JSONString) . Utilization of trace level logging on the RequestStatistics node showed no additional transient object created when the microflow was called. (As opposed to 50+ during 7.18/19 successful operation) Any action on the pop-up will, at this point, result in repeated errors containing the trace, and further urgings to see the administrator. I'm baffled, and the only conclusion I can come to is that the transient objects are being killed much sooner than they should be. I know that Alpha is created, since some of its information is used to write labels, but of its two associated arrays of transients there is no trace. Has anyone encountered this issue before? PS. I've tried to submit this as a support ticket, but the reCAPTCHA would barely stay up on screen long enough on Chrome/Firefox/Edge for long enough for my beleaguered brain to recognize that a CAPTCHA window had appeared before whisking me away and telling me I'd failed my CAPTCHA. On IE the page just never loaded past me selecting the 'incident' dropdown.
I reproduced the error in a small test project and was able to find a workaround for our situation, maybe this can help you to.
I traced it down to an on change microflow which refreshed our non-persistent entity when an input set reference selector was changed. The change action used for this had commit set to Yes, when i set this to No the problem no longer occurs.
You're a lifesaver, mate. I reorganized the commits to take it down to a single operation, and that fixed it. Then worked back on the original and discovered that the commit that caused the crash was a commit inside a subflow that tacked on the two transient lists.