{"action":"created","issue":{"url":"https://api.github.com/repos/gravitational/trace/issues/41","repository_url":"https://api.github.com/repos/gravitational/trace","labels_url":"https://api.github.com/repos/gravitational/trace/issues/41/labels{/name}","comments_url":"https://api.github.com/repos/gravitational/trace/issues/41/comments","events_url":"https://api.github.com/repos/gravitational/trace/issues/41/events","html_url":"https://github.com/gravitational/trace/issues/41","id":280250083,"number":41,"title":"Ability to include contextual information / tags with error results","user":{"login":"knisbet","id":12373072,"avatar_url":"https://avatars3.githubusercontent.com/u/12373072?v=4","gravatar_id":"","url":"https://api.github.com/users/knisbet","html_url":"https://github.com/knisbet","followers_url":"https://api.github.com/users/knisbet/followers","following_url":"https://api.github.com/users/knisbet/following{/other_user}","gists_url":"https://api.github.com/users/knisbet/gists{/gist_id}","starred_url":"https://api.github.com/users/knisbet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/knisbet/subscriptions","organizations_url":"https://api.github.com/users/knisbet/orgs","repos_url":"https://api.github.com/users/knisbet/repos","events_url":"https://api.github.com/users/knisbet/events{/privacy}","received_events_url":"https://api.github.com/users/knisbet/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-12-07T19:29:11Z","updated_at":"2017-12-07T20:40:52Z","closed_at":null,"author_association":"NONE","body":"Looking at another issue, there is a desire to suppress errors in portions of code due to user input to keep the logs clean. For example, an API where hitting an invalid input generates an error, that's presented to the user and not considered worth logging.\r\n\r\n```\r\nif !trace.IsNotFound(err) {\r\n  log(err)\r\n}\r\n```\r\n\r\nHowever, for code that's unrelated to the API, that generates a NotFound error will inadvertently be suppressed as well.\r\n\r\nThe idea Sasha had, would be to be able to Tag errors, so for example the API code could tag it's NotFound errors, and then only suppress logging errors with a matching tag. I think there is another area that would benefit, is we use retries in several area's, but often we're missing context on errors, on whether the errors is a permanent or temporary failure. A project could adopt a set of best practices for which tags to include with certain types of errors.\r\n\r\nlogrus for structured logging provides a similar methodology with fields that may be worth considering.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/gravitational/trace/issues/comments/350087828","html_url":"https://github.com/gravitational/trace/issues/41#issuecomment-350087828","issue_url":"https://api.github.com/repos/gravitational/trace/issues/41","id":350087828,"user":{"login":"DenisMishin","id":673131,"avatar_url":"https://avatars0.githubusercontent.com/u/673131?v=4","gravatar_id":"","url":"https://api.github.com/users/DenisMishin","html_url":"https://github.com/DenisMishin","followers_url":"https://api.github.com/users/DenisMishin/followers","following_url":"https://api.github.com/users/DenisMishin/following{/other_user}","gists_url":"https://api.github.com/users/DenisMishin/gists{/gist_id}","starred_url":"https://api.github.com/users/DenisMishin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DenisMishin/subscriptions","organizations_url":"https://api.github.com/users/DenisMishin/orgs","repos_url":"https://api.github.com/users/DenisMishin/repos","events_url":"https://api.github.com/users/DenisMishin/events{/privacy}","received_events_url":"https://api.github.com/users/DenisMishin/received_events","type":"User","site_admin":false},"created_at":"2017-12-07T20:40:52Z","updated_at":"2017-12-07T20:40:52Z","author_association":"CONTRIBUTOR","body":"Custom tagging could be a powerful extension to `trace`:\r\n\r\n1. Currently, various error classes are acting as a kind of tags, and sometimes modules may have their specific internal error types to handle. \r\n2. This would play well with structured loggers including `logrus`. \r\n3. This would solve some of the nested wait.Retry cases, as it will signal that certain error doesn't make sense to retry (i.e. if it's caused my misconfiguration)\r\n\r\nAn ability to append context such as current config parameters, etc would also benefit the top-level errors appearing in the logs. "}}
{"actor":{"display_login":"DenisMishin"}}