That seems like the best workaround for now. Another idea is to put stuff like that into the prc (assuming it isn’t passed to interceptors too).
Would you mind entering a ticket in our JIRA for this so we can track it? We may come up with some ideas to get it to work, or at least handle the error better.
https://www.ortussolutions.com/blog/how-to-create-a-jira-account-and-enter-coldbox-tickets
I’m told you are just down the street from us
Ahh yes, at you’re at Uhlig. They’ve got a nice sized team over there. Maybe enough to get the KC CFUG going again 
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Brad,
I just did an experiment and the same thing happens if there is an object anywhere in prc.
Will add a ticket to your Jira.
Thanks again!
This is an issue that I am not sure it is possible to tackle in a global approach, since async interceptors just detach the request context. However, I will investigate further. What I would suggest is adding a serializable=false on objects that might end up there.
However, I will investigate
Just fyi, adding “serializable=false” to the config of the ORM entity in question did not change anything.
When you say config, do you mean an annotation on the component tag?
component serializable=false {
…
}
or
...
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Yes, that is what I did. Sorry I’m still learning the lingo. We also tried adding it to our Base ORM class (making every ORM entity un-serializeable) and received the same 500 internal server error.