I can't open the main file because it's referencing a custom class. However, I do see you said the defects solve your issue, in that, it's just broken, and you need to reconfigure your solution.
I am curious if it works or not, so I'll still try it myself. Though, this isn't something I've ever done. The trigger app step for me only have value in its ability to be ran asynchronously, otherwise, I would call redirect to another trigger or call subflow to another script depending on the situation.
I can open the triggered script, and I don't see why, unless you remove some steps, you are getting the session and answering the contact. Neither of those steps seem to be necessary.
EDIT: After playing around with this a bit, I can already see a potential issue. If you are not keeping the original script alive, where --Triggering Contact-- is referring to the caller, then the second script will lose it's Contact. You see, even in Callback solutions, where two scripts share a reference to the --Triggering Contact--, the script which "creates" the Contact will "clean up" the Contact if the script ends. Therefore, if you need the Contact to stay active and in use, so you can interact with it in another script like this, then you need to keep the original script active the entire time. Which, if you think about it, is a waste of resources, holding two or more scripts in memory just to queue and answer a call. Even with a subflow as a workaround this is doing the same thing. It would be better to use Call Redirect, so you can free up resources as you pass the caller around the system.
Anyway, since I cannot see your full solution, I'm just guessing that this is the issue you're running into. If you can remove the dependency on the external java class, I could then look at it closer. I'll keep researching the solution on my end too; as I'm not quite done yet.
EDIT 2: Ok, so I've done some light testing on this and I have a hypothesis. Similar to what I was saying about cleaning up resources when a script ends, I believe the originating application where the contact was created, is the only application which can be triggered by the interruptible nature of the Select Resource step. The event seems to be missing the target trying to be executed, because it doesn't exist within the context of the originating App.
I've never done it this way before, so I learned something here. Too bad the Trigger Application step isn't more robust, but that's how it is.
