When using federation, one intuitively expects the 'exchange' field inside the
x-received-from: header table to state the upstream exchange
name, rather than the downstream name to which the message was 'republished', in
cases where the exchange names were not the same.
We are running 3.5.7 and are finding the latter in messages collected
downstream.
To someone troubleshooting, investigating the origin of a federated message, this would obviously be misleading.
Michael K. initially commented 'obtaining upstream exchange can be quite tricky, in particular
for multi-hop setups' - I wasn't sure why, since there can be multiple blocks of federation history inside the x-received-from: table, and I would assume the federation plugin at each stage would simply record where its message came from.
Also perhaps instead of creating yet more headers to clearly record "downstream-exchange" and "upstream-exchange", there could be a RMQ federation config setting, which would either preserve the original semantic, or use the new one where 'exchange:' records the upstream name?
Those using different up/downstream exchange names seem to be in a fairly small minority, and hopefully only a minority of them would be relying on the non-intuitive interpretation of that exchange header. Those people could simply use the config setting to preserve the 'old' behavior they depend on. That would allow the intuitive interpretation to be the default going forward.
Just some ideas.
Thanks...
When using federation, one intuitively expects the 'exchange' field inside the x-received-from: header table to state the upstream exchange name, rather than the downstream name to which the message was 'republished', in cases where the exchange names were not the same. We are running 3.5.7 and are finding the latter in messages collected downstream. To someone troubleshooting, investigating the origin of a federated message, this would obviously be misleading.
Michael K. initially commented 'obtaining upstream exchange can be quite tricky, in particular for multi-hop setups' - I wasn't sure why, since there can be multiple blocks of federation history inside the x-received-from: table, and I would assume the federation plugin at each stage would simply record where its message came from.
Also perhaps instead of creating yet more headers to clearly record "downstream-exchange" and "upstream-exchange", there could be a RMQ federation config setting, which would either preserve the original semantic, or use the new one where 'exchange:' records the upstream name? Those using different up/downstream exchange names seem to be in a fairly small minority, and hopefully only a minority of them would be relying on the non-intuitive interpretation of that exchange header. Those people could simply use the config setting to preserve the 'old' behavior they depend on. That would allow the intuitive interpretation to be the default going forward. Just some ideas. Thanks...