Nservicebus: TimeToBeReceivedOnForwardedMessages not working

[timbussmann]

I noticed we still offer the config-section only option to configure a TTBR for forwarded messages via UnicastBusConfiguration section. This option doesn't seem to work at all though:

• MSMQ throws an exception because of the transaction issues with the TTBR header
  
  
  
  • It doesn't throw an exception when not using transactions, but also it doesn't apply the ttbr configuration to the message, therefore setting an infinite TTBR.
  
  
• RabbitMQ doesn't seem to respect this configuration option neither. I didn't test for further transports but I assume that other transports won't implement this.
• I found no documentation on the forwarding doco page (https://docs.particular.net/nservicebus/messaging/forwarding).

Given the fact that we want to get rid of the config section, this option will disappear from the API surface anyway. Do we treat this as won't fix or should we provide a proper code first API (which it doesn't have yet) and ensure via tests that core/transports apply this setting correctly?

[andreasohlund]

The TTBR option was a left over from the days when forwarding == audit. Now that we have a dedicated feature for auditing I don't see any use case for applying ttbr on forwarding.

Forwarding == forward an exact copy of the incoming message to X.

In short:

I vote for a close as won't fix

[WilliamBZA]

Decided it is best to obsolete the XML parameters as part of v6.2 via detecting and warning in the log.

If v6.3 happens, the warn should change to an error.

Final removal to happen in v7.

[danielmarbach]

What if an endpoint forwards all incoming messages to a secondary that should keep the messages for a time windows of X days? Or is this a totally made up scenario?

[WilliamBZA]

Why would they not use the auditing plugin for that?

[timbussmann]

I see the forwarding feature to be usable in case you actually want to process messages on a second endpoint. In that case it seems to be a very edge case scenario to also state lifetime requirements on those forwarded messages and something which should rather be handled by the receiving endpoint? Whereas with auditing you usually don't have a receiver on the audit queue (except SC of course) which means that you might want to use TTBR as a mechanism to manage the queue size.

I think it's a valid point raised by @danielmarbach but my currently remains at "won't fix".

[timbussmann]

as no more objections have been raised an no user reported this feature as not working in the v6 release, I think we can close this as won't fix. Happy if somebody wants to bring this up as a feature request though.

[andreasohlund]

I think Won't fix is correct, forwarding should IMO mean "forward a exact copy of the incoming message to endpoint X", this should should include TTBR