{"action":"created","issue":{"url":"https://api.github.com/repos/Particular/NServiceBus/issues/2368","labels_url":"https://api.github.com/repos/Particular/NServiceBus/issues/2368/labels{/name}","comments_url":"https://api.github.com/repos/Particular/NServiceBus/issues/2368/comments","events_url":"https://api.github.com/repos/Particular/NServiceBus/issues/2368/events","html_url":"https://github.com/Particular/NServiceBus/issues/2368","id":42479573,"number":2368,"title":"Send/store metadata for error/audit metadata separately to original message","user":{"login":"SimonCropp","id":122666,"avatar_url":"https://avatars.githubusercontent.com/u/122666?v=3","gravatar_id":"","url":"https://api.github.com/users/SimonCropp","html_url":"https://github.com/SimonCropp","followers_url":"https://api.github.com/users/SimonCropp/followers","following_url":"https://api.github.com/users/SimonCropp/following{/other_user}","gists_url":"https://api.github.com/users/SimonCropp/gists{/gist_id}","starred_url":"https://api.github.com/users/SimonCropp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SimonCropp/subscriptions","organizations_url":"https://api.github.com/users/SimonCropp/orgs","repos_url":"https://api.github.com/users/SimonCropp/repos","events_url":"https://api.github.com/users/SimonCropp/events{/privacy}","received_events_url":"https://api.github.com/users/SimonCropp/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Particular/NServiceBus/labels/Impact:%20M","name":"Impact: M","color":"e11d21"},{"url":"https://api.github.com/repos/Particular/NServiceBus/labels/Order:%20Short%20Term%20Focus","name":"Order: Short Term Focus","color":"eb6420"},{"url":"https://api.github.com/repos/Particular/NServiceBus/labels/Type:%20Feature","name":"Type: Feature","color":"02e10c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":34,"created_at":"2014-09-11T01:14:18Z","updated_at":"2015-10-22T09:38:18Z","closed_at":null,"body":"So exceptions stack trace can be very large. should we trim them?\r\n\r\nShould the transport supply the \"how long\"?\r\n\r\n---\r\n*update by @adamralph*\r\n\r\n### Problem\r\n\r\nE.g. when an exception is thrown from a handler and the exception message is large, the error message we create and send to the error queue may cause the transport to refuse the message since we copy the exception message into the headers. In this scenario the endpoint is stopped and the original message remains in the queue.\r\n\r\nThis problem generalises to any point where we add headers to a message or tamper with it in any other way. This is a fundamental design flaw. We should keep the additional metadata separate from the original message.\r\n\r\nIn https://github.com/Particular/NServiceBus/issues/2956 we hardcoded the error message size limit to 16,384 to overcome an immediate problem for a customer using the RabbitMQ transport but this does not fix the problem generally. Nor did it solve the problem for that customer in all cases. Since the fix, the customer is sending even larger messages and the hardcoded limit of 16.384 it still too high. A new bug has been raised to reflect their current problem #3023.\r\n\r\nThe suggested plan of attack is that we will not fix bug #3023 as it is effectively unfixable in all current major versions due to a design flaw which would require a breaking change to re-mediate. Instead we will attempt to offer the customer a workaround. We will offer this feature in v6 and recommend an upgrade to avoid the problem and any workarounds.\r\n\r\n### Plan of Attack\r\n\r\n- [ ] *TBD*\r\n- [ ] Prepare docs\r\n- [ ] Prepare announcement\r\n- [ ] Release\r\n- [ ] Publish docs"},"comment":{"url":"https://api.github.com/repos/Particular/NServiceBus/issues/comments/150162471","html_url":"https://github.com/Particular/NServiceBus/issues/2368#issuecomment-150162471","issue_url":"https://api.github.com/repos/Particular/NServiceBus/issues/2368","id":150162471,"user":{"login":"timbussmann","id":3524870,"avatar_url":"https://avatars.githubusercontent.com/u/3524870?v=3","gravatar_id":"","url":"https://api.github.com/users/timbussmann","html_url":"https://github.com/timbussmann","followers_url":"https://api.github.com/users/timbussmann/followers","following_url":"https://api.github.com/users/timbussmann/following{/other_user}","gists_url":"https://api.github.com/users/timbussmann/gists{/gist_id}","starred_url":"https://api.github.com/users/timbussmann/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/timbussmann/subscriptions","organizations_url":"https://api.github.com/users/timbussmann/orgs","repos_url":"https://api.github.com/users/timbussmann/repos","events_url":"https://api.github.com/users/timbussmann/events{/privacy}","received_events_url":"https://api.github.com/users/timbussmann/received_events","type":"User","site_admin":false},"created_at":"2015-10-22T09:38:18Z","updated_at":"2015-10-22T09:38:18Z","body":"but we're heavily relying on custom headers, not only for auditing. While long exception messages may be the obvious failure reason, even adding a SLR header may exceed the transport size limit, right?\r\n\r\nI do not fully agree on the \"data loss\" argument when truncating exception messages. The exception message doesn't belong to the \"data\", the original message and it's headers are the data. The exception should also be logged fully in the endpoint's log file. Therefore truncating the exception is no data loss at all. That information is not relevant for processing data, it's a helpful information for the user to avoid going through tons of log files."}}