A technical point. Asterisk is a back to back user agent and will never relay a re-invite; it will generate a new invite based no the updated address information.
However, this situation should not cause one way audio, it should just result in Asterisk relaying RTP to a different address. You cannot pass an invalid address in a re-invite with the expectation that it will be forwarded; there are no guaranteed semantics for B2BUAs in this respect.
In particular, if you have configured anything that is incompatible with external bridging, e.g. directmedia=no, monitoring, enabling T, t, or other features, etc., on the Dial application, Asterisk has to retain the RTP stream. Also, when party B clears, Asterisk will re-invite party A back, even if there was an external bridge.
Having said that, there was a recent bug report external bridging failing to propagate across chains of Asterisks, so you may have hit a bug.