I’m not sure how to repro the exact error in this ticket, but I have added my fix and the tests are all passing. I have defaulted parallel discovery again.

On a side note, we’re losing some “caused by” info here. The outer stack trace simply tells us something deep inside the beforeApplicationListenerLoad interceptor has fired. The only “cause by” we have is the code that ran inside of thread. However, we’re missing the part of the stack that shows the code that was running inside of the ORM module that led up to the threading. We should track down where that is getting lost. I’m also not a super fan of the interceptor service wrapping the exceptions at all. It doesn’t tell me much I wouldn’t already know since the method name inside the interceptor tells me exactly what interception point was being responded to!

That fix makes sense. I assigned the ticket to myself since I was at’ed but I'm out at the moment and won't be able to fix it until tonight. I'm happy to work on it later or if you don't want to wait for me feel free to steal this ticket 😁

The fix is to create a context for each thread to use, whose parent is the original context. That will allow things like mappings to still be available from the original request, but each thread can push/pop templates on its own local context.

The issue is the context pushing and popping of the templates. They are external to the visitor. So in order to have concurrency, we need this to either lock, or try to avoid pushing and popping on the same context.