That's an interesting problem. AFAIK sync transport was created mainly for testing purpose. Basically sync transport is just like no transport at all, it's a synchronous code execution so at the first glance it should not be surprising that the whole process crashes. However I agree that we can discuss whether the behavior of sync transport in context of failed messages should be redefined.

For my use case, I think it makes sense to retain the current behaviour of crashing the whole process or making it configurable, so this behaviour can be retained.

I have message handlers where a synchronous handler records some domain interaction, and a series of queued asynchronous handlers provision a number of resources that follow from that interaction. Occasionally the synchronous handler may throw some invariant exception, where all of the resources provisioned asynchronously should be halted and discarded.

A "safe-sync://" transport would be a good way to support both use cases.

sync:// dsn + retry_strategy/failure_transport should work as expected IMHO

My use-case is to make an automatic retry mechanism for deadlocks and lock wait timeouts using the sync:// in a command bus. With this I also run into the issue that throwing an exception does not go into the retry as configured. Not using a transport currently also doesn't let you use a retry unless you make a custom middleware to deal with this.