We've had a few discussions about this in IRC, but thought I'd post an update on some investigations I did earlier in case it helps anyone.
I've seen a few problems lately where exceptions being thrown in plan functions are being caught and silently swallowed, making it difficult to debug problems. Here's an example of what it looks like in logging:
17:27:12.026 [operate-13] DEBUG pallet.crate.app-deploy - deploy :sautee : {:local-file "target/Sautee-0.3.0-SNAPSHOT-standalone.jar", :project-path "target/Sautee-%s-standalone.jar", :path "/opt/sautee.jar"} to /opt/sautee.jar
17:27:12.030 [operate-11] DEBUG pallet.algo.fsm.event-machine - Locking transition
17:27:12.031 [operate-11] DEBUG pallet.algo.fsm.event-machine - :dofsm-reduce* - in state :running fire :step-fail
17:27:12.032 [operate-11] DEBUG pallet.algo.fsmop - seq-running
17:27:12.032 [operate-11] DEBUG pallet.algo.fsm.event-machine - Locking transition
17:27:12.033 [operate-11] DEBUG pallet.algo.fsm.event-machine - :dofsm-reduce* - in state :step-failed fire :fail
So you can see the step failed, but no clues as to what happened.
I hooked up YourKit and tracked Exceptions to figure out what was going on. It's fairly straight-forward to guess which Exception instance is relevant, as there'll be relatively few instances of ExceptionInfo (or whatever Exception class is thrown), and even fewer from the "operate-n" thread running the action.
In this case, I found an exception coming from "verify-local-file-exists" in remote-file, so guessed that my jar file wasn't actually there (d'oh!).
Jaley.