dlemire60
commented
2 years ago Discussed at 8/10 working meeting. Consensus was that a failure to fully decode a command was an Internal Error and that partial success could not be relied on.
The primary purpose of creating the (RR = None) option was to reduce / avoid unnecessary network traffic (e.g., a command send to 1,000s of consumers in parallel). Consensus in meeting was that reporting failure is more important than reducing the traffic load in the circumstances described, and an error response should be returned. @dlemire60 took an action to prepare a corresponding PR.
With the response_requested field being part of the message body, inside the arguments, if the Consumer fails to deserialize the message it will send an error back even if the original command was sent as response_requested NONE. Cannot determine a way to get around this without making serialization error handling impossible, allowing NONE responses to still respond in this way, or moving this to some fixed part of the header. What level of concern is it that NONE response messages act fully silently?
(source: HII software team)