{"action":"created","issue":{"url":"https://api.github.com/repos/Valloric/ycmd/issues/430","repository_url":"https://api.github.com/repos/Valloric/ycmd","labels_url":"https://api.github.com/repos/Valloric/ycmd/issues/430/labels{/name}","comments_url":"https://api.github.com/repos/Valloric/ycmd/issues/430/comments","events_url":"https://api.github.com/repos/Valloric/ycmd/issues/430/events","html_url":"https://github.com/Valloric/ycmd/issues/430","id":140434492,"number":430,"title":"Strange caching behavior on completions requests","user":{"login":"vincentwoo","id":613320,"avatar_url":"https://avatars.githubusercontent.com/u/613320?v=3","gravatar_id":"","url":"https://api.github.com/users/vincentwoo","html_url":"https://github.com/vincentwoo","followers_url":"https://api.github.com/users/vincentwoo/followers","following_url":"https://api.github.com/users/vincentwoo/following{/other_user}","gists_url":"https://api.github.com/users/vincentwoo/gists{/gist_id}","starred_url":"https://api.github.com/users/vincentwoo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vincentwoo/subscriptions","organizations_url":"https://api.github.com/users/vincentwoo/orgs","repos_url":"https://api.github.com/users/vincentwoo/repos","events_url":"https://api.github.com/users/vincentwoo/events{/privacy}","received_events_url":"https://api.github.com/users/vincentwoo/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":16,"created_at":"2016-03-13T01:26:16Z","updated_at":"2016-03-26T01:44:23Z","closed_at":"2016-03-26T01:44:23Z","body":"Hi there,\r\n\r\nIn testing YCMD as a remote completion API, I appear to be hitting a weird caching bug. I'm just testing against Jedi autocompletion currently.\r\n\r\nFor the buffer\r\n\r\n```python\r\nimport requests\r\nimport datetime\r\n\r\nrequests.\r\n```\r\n\r\nI (on the remote server where ycmd is running), write out the buffer to the filesystem, send a `FileReadyToParse` event to YCMD, and then ask for completions. This works okay, I get the appropriate results for `requests`.\r\n\r\nHowever, If I change the buffer to:\r\n\r\n```python\r\nimport requests\r\nimport datetime\r\n\r\ndatetime.\r\n```\r\n\r\nand perform the same actions, I still get returned the completion results for `requests` and not `datetime`. I believe this to be because of YCMD's caching on line and character offsets. Is there an API for saying \"this buffer needs to be reparsed\"? I couldn't find one in the sample client."},"comment":{"url":"https://api.github.com/repos/Valloric/ycmd/issues/comments/201656058","html_url":"https://github.com/Valloric/ycmd/issues/430#issuecomment-201656058","issue_url":"https://api.github.com/repos/Valloric/ycmd/issues/430","id":201656058,"user":{"login":"Valloric","id":919444,"avatar_url":"https://avatars.githubusercontent.com/u/919444?v=3","gravatar_id":"","url":"https://api.github.com/users/Valloric","html_url":"https://github.com/Valloric","followers_url":"https://api.github.com/users/Valloric/followers","following_url":"https://api.github.com/users/Valloric/following{/other_user}","gists_url":"https://api.github.com/users/Valloric/gists{/gist_id}","starred_url":"https://api.github.com/users/Valloric/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Valloric/subscriptions","organizations_url":"https://api.github.com/users/Valloric/orgs","repos_url":"https://api.github.com/users/Valloric/repos","events_url":"https://api.github.com/users/Valloric/events{/privacy}","received_events_url":"https://api.github.com/users/Valloric/received_events","type":"User","site_admin":false},"created_at":"2016-03-26T01:44:23Z","updated_at":"2016-03-26T01:44:23Z","body":"I've discussed this issue with @micbou and @puremourning and we've come to the conclusion that this is a rare corner-case that doesn't really impact clients that ycmd is designed to support, namely localhost editors with one editor instance (used by one user) mapping to one ycmd instance. The user editing the buffer would invalidate the cache before `requests.` became `datetime.` so this would never occur. \r\n\r\nIt can only arise in what ycmd would consider uncommon cases that the designed-for category of clients would rarely if ever produce. Solutions to fix this involve a loss of performance for _all_ cases or other corner-case problems, so fixes aren't free.\r\n\r\nSince the current caching logic has been in place for 3+ years without much (if any, as I recall) complaints about this until now, it doesn't seem worth fixing.\r\n\r\nThanks for filing an issue though! We'll keep this in mind in case it rears its head in other circumstances."}}