{"action":"opened","issue":{"url":"https://api.github.com/repos/anxiousmodernman/sjkjmj/issues/52","repository_url":"https://api.github.com/repos/anxiousmodernman/sjkjmj","labels_url":"https://api.github.com/repos/anxiousmodernman/sjkjmj/issues/52/labels{/name}","comments_url":"https://api.github.com/repos/anxiousmodernman/sjkjmj/issues/52/comments","events_url":"https://api.github.com/repos/anxiousmodernman/sjkjmj/issues/52/events","html_url":"https://github.com/anxiousmodernman/sjkjmj/issues/52","id":177617929,"number":52,"title":"Prevent Cyclical Feedback Loops from Processing Events","user":{"login":"anxiousmodernman","id":396004,"avatar_url":"https://avatars.githubusercontent.com/u/396004?v=3","gravatar_id":"","url":"https://api.github.com/users/anxiousmodernman","html_url":"https://github.com/anxiousmodernman","followers_url":"https://api.github.com/users/anxiousmodernman/followers","following_url":"https://api.github.com/users/anxiousmodernman/following{/other_user}","gists_url":"https://api.github.com/users/anxiousmodernman/gists{/gist_id}","starred_url":"https://api.github.com/users/anxiousmodernman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/anxiousmodernman/subscriptions","organizations_url":"https://api.github.com/users/anxiousmodernman/orgs","repos_url":"https://api.github.com/users/anxiousmodernman/repos","events_url":"https://api.github.com/users/anxiousmodernman/events{/privacy}","received_events_url":"https://api.github.com/users/anxiousmodernman/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-09-17T23:39:52Z","updated_at":"2016-09-17T23:39:52Z","closed_at":null,"body":"@coleman.mcfarland \r\n\r\nDuring analytics, in order to prevent feedback loops when responding to events triggered by our own use of the API, we need a way to filter out such events.  We also already have a related problem just as a user when going through logs of all the http requests.  It's the basic problem of attributing a session to a particular task.\r\n\r\nIf we had a client-supplied http header \"Task\", it can be set the same for all http requests that are performing the same task.  For GET URLs, Task might be an optional parameter for every endpoint (i.e.: so that file downloads are properly attributed to a particular instance of the UI in the cases where we can't easily set headers on the request).\r\n\r\nTask should be logged the same as the sessionid and node id, and should show up in all events.  This way, anybody listening to the kafka queue can easily filter them out, or know to not respond to them.  For a UI client, the Task would probably be set when the UI loads in the browser.  It would probably be a free-form format, so that it could be things like: \"analytics-e9245a4c\", or \"drive-0dc423ab\".  When going through events and logs, we can filter and grep based on this hierarchy:\r\n\r\n```\r\n#a user may be invoking many nodes, and require many sessions to perform a task\r\nuser0/node0/task0/session0: event0\r\nuser0/node0/task0/session1: event1\r\nuser0/node1/task0/session2: event2\r\n...\r\n```\r\n\r\nTask is necessary because session is server-supplied and unique per http request, while only the client actually knows when to reuse a task id or create a new one.\r\n\r\nAnalytics tasks in general may need to be filtered out completely.  That could be done by having a naming convention on them."}}
{"actor":{"display_login":"anxiousmodernman"}}