{"action":"closed","issue":{"url":"https://api.github.com/repos/elastic/elasticsearch/issues/6252","labels_url":"https://api.github.com/repos/elastic/elasticsearch/issues/6252/labels{/name}","comments_url":"https://api.github.com/repos/elastic/elasticsearch/issues/6252/comments","events_url":"https://api.github.com/repos/elastic/elasticsearch/issues/6252/events","html_url":"https://github.com/elastic/elasticsearch/issues/6252","id":33960959,"number":6252,"title":"Benchmark API might miss not yet starting benchmark in unabortable state","user":{"login":"s1monw","id":973334,"avatar_url":"https://avatars.githubusercontent.com/u/973334?v=3","gravatar_id":"","url":"https://api.github.com/users/s1monw","html_url":"https://github.com/s1monw","followers_url":"https://api.github.com/users/s1monw/followers","following_url":"https://api.github.com/users/s1monw/following{/other_user}","gists_url":"https://api.github.com/users/s1monw/gists{/gist_id}","starred_url":"https://api.github.com/users/s1monw/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/s1monw/subscriptions","organizations_url":"https://api.github.com/users/s1monw/orgs","repos_url":"https://api.github.com/users/s1monw/repos","events_url":"https://api.github.com/users/s1monw/events{/privacy}","received_events_url":"https://api.github.com/users/s1monw/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/elastic/elasticsearch/labels/critical","name":"critical","color":"eb6420"},{"url":"https://api.github.com/repos/elastic/elasticsearch/labels/stalled","name":"stalled","color":"fef2c0"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2014-05-21T08:15:35Z","updated_at":"2015-08-26T14:59:48Z","closed_at":"2015-08-26T14:59:48Z","body":"Today there is a race condition in how we handle the benchmark state that allows for benchmarks to be kicked off without the ability to abort them again. The main reason for this is that the state handling is flawed since applying the state is not serializable in a way that the executing nodes knows if a benchmark that is marked as `running` has been aborted. The abort call simply tires to stop the benchmark and if it's not in the executing nodes datastructure due to some sort of a delay or an exhausted threadpool it just ignores it. At that point the benchmark state is already updated in the cluster state and can not be aborted again.  \r\n\r\nThe solution to this is a bigger change though. We should move to cluster state listeners instead of per node RPC calls just like Snapshot & Restore works"}}