Community
Participate
Working Groups
I rather frequently get "Task not found:" error messages in git log, which requires me to reload the page. I finally found a reproducible scenario. - open a git log page. - click on the commit link to see the commit - now go back in browser history to the git log page. You'll get a "task not found". If you push reload quickly, it will usually still fail. If you take a deep breath and count to 10 and reload, it will come back.
I was only able to reproduce it on Chrome and I'm pretty sure that this is a symptom of a wider problem with Chrome. The problem is that response for git log is retrieved from cache, although we add a non-cache header to the response. What is more other responses from our servlets are as well retrieved from cache, but the task is response is the only one that causes the real problem, because the task returned by the previous git log was deleted in meantime. >If you push reload quickly, it will usually still fail. >If you take a deep breath and count to 10 and reload, it will come back. I had just the same problem, reloading with F5+F5 forced to get the correct response and everything worked fine. Simon, do I remember correctly that it was you solving the cache problem before, by adding "Cache-Control: no-cache" to OrionServlet.writeJSONResponse? It seems that Chrome doesn't respect the no-chache header, see this: http://code.google.com/p/chromium/issues/detail?id=64139 I played a little with the scenario Susan found and it looks like adding "no-store" to Cache-Control header solved this problem, but this has a wide effect and I don't want to make this decision by myself. What do you think about solving this by adding response.addHeader("Cache-Control", "no-store") to writeJSONResponse? Alternatively I can use it only where we return information abut tasks, but I don't think we would like to risk caching other json responses.
(In reply to comment #1) > What do you think about solving this by adding > response.addHeader("Cache-Control", "no-store") to writeJSONResponse? Ah and I also think that we may justify no-store, because json responses may contain some information available to authenticated user, so may be considered as sensitive data.
(In reply to comment #1) > I was only able to reproduce it on Chrome and I'm pretty sure that this is a > symptom of a wider problem with Chrome. I was on Chrome too...sorry for not saying so.
I tried to reproduce the caching problem in few places and it seems that it doesn't occur every time in Back. One other scenario I found requires Orion running in two browsers: 1. Open git status in Chrom and FF (need some files unstaged) 2. Stage a file in FF 3. On Chrome click on one of the commits in minilogs to open its details 4. Hit back on Chrome 5. Git status on Chrome does not contain the file staged in 2. as staged [BUG] 6. Refresh, still file is not staged [BUG] 7. Hard refresh (F5+F5). File is in staged I doublechecked that git status response gas "no-cache" header set.
Created attachment 210317 [details] proposed fix - adding no-store
Simon, as we talked on the call, I propose to fix this issue by adding no-store to our json responses (see patch), but I don't want to make this decision by myself, so I'm adding you on review. If you are ok with it I'll commit the "no-store" fix.
Go for it. At worst its correct but slower however from what I've seen it just looks like it's correct.
Pushed.
