Nit pick - this is really aDefinition, not aReference

these should be references, right? We don't normally set a Definition directly on an argument. And should it use$failureTransportsServiceLocatorId or$failureTransportsServiceLocator - I'm getting lost (this stuff confuses me) in which is which and what should be used.

Same problem here (ish) as below - we should pass a Reference (which$failureTransportsServiceLocator is), not a Definition.

we could revert this change to lessen the diff

Should we be checking for!isset($senderReferences[$transport['failure_transport']]) here instead? That would be consistent with the above code. It's more confusing, but there is the edge case that the failure_transport is not a registered transport, but just a "sender service id"

If I'm correct inFrameworkExtension, these won't be needed.

Hmm, wait a second. This is subtle. But currently, inFrameworkExtension, you are populating arg 0 with$senderReferences[$config['failure_transport']]. But before, we were populating them withreceiver references. Even for me, this makes my head spin a bit :P. You could technically have a failure transport "receiver" service but no "sender" service... though this is (at the very least) an edge case. Usually a sender & receiver are a "pair" because you've defined them as a transport. But this doesn't need to be the case.

The situation would be this: I create aReceiverInterface service and tag it withmessenger.receiver andaliasmy_failure_receiver. But, I do not actually register this as a transport. Then, at the command line, I usemessenger:failure:show --failure-transport=my_failure_receiver. That is technically legal. And it's even possible (though unlikely) to set up this kind of situation if you're using AMQP (e.g. you actually set up a truefailure_transport calledfailure1, but then with custom binding & routing rules, those messages ultimately end up in a queue connected with the custommy_failure_receiver receiver.

So.... that's why this code was originally here and I think it probably still needs to be. I don't think that's a problem, other than some of the new code inFrameworkExtension should actually live here.