Community
Participate
Working Groups
Currently, when you open a review that has been opened before, the patch set isn't loaded by default. We did that as part of the effort to simplify the model update process and move to a pure TaskData based approach. But this leads to annoying behavior, in that you have to manually load the task. This is due to the fact that we no longer ask for an update when we first load a model. Although this is reasonable to fit in with update strategy, the problem is that we don't have the remote object which we need for compare operations and the like. So I'm going to look at grabbing the remote object and updating anyway, even though to some extent that duplicates the role of Task Data.
https://git.eclipse.org/r/13998 I also noticed a tricky issue with TaskData where we often are trying to update at the same time the user has just trigerred a retrieval. I think fixing this should improve retrieval behavior.
I occasionally get warnings like this in the log and the editor fails to load a particular patch set. While I'm not sure what is causing the problem (could be comment 1) the error message also doesn't tell me anything beyond what I already now. It should include the exception that caused the operation to fail (i.e. the IOException or whatever). Couldn't update model. org.eclipse.core.runtime.CoreException: Couldn't obtain patch set detail for 2. Check remote connection. at org.eclipse.mylyn.internal.gerrit.core.remote.PatchSetContentIdRemoteFactory.pull(PatchSetContentIdRemoteFactory.java:53) at org.eclipse.mylyn.internal.gerrit.core.remote.PatchSetContentIdRemoteFactory.pull(PatchSetContentIdRemoteFactory.java:1) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.pull(RemoteEmfConsumer.java:164) at org.eclipse.mylyn.reviews.core.spi.remote.JobRemoteService$1.run(JobRemoteService.java:60) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
(In reply to comment #2) > I occasionally get warnings like this in the log and the editor fails to load a > particular patch set. While I'm not sure what is causing the problem (could be > comment 1) the error message also doesn't tell me anything beyond what I already > now. It should include the exception that caused the operation to fail (i.e. the > IOException or whatever). Yeah, the error is really misleading. The problem is that we don't really know at this point why we couldn't retrieve the patch set detail. This is a bit of an odd case, because we actually retrieve all of that information when we retrieve the Review (Gerrit Change). However, each PatchSet has its own RemoteConsumer, so that we can map the model object (IReviewItemSet) to the remote object (PatchSetDetail). So all the "pull" is doing at this point is returning the PatchSetDetail that "should" already be there. We're just surmising that it was because of an early connection error. But if we're getting this error and we don't see a previous connection issue, then there is something else going wrong here and I'm not sure what it is. That's what I need to investigate.
Please review https://git.eclipse.org/r/#/c/13998/11 . I'd like to get this change in as it fixes some real annoyances. As long as it doesn't break anything else we can always add additional improvements on an on-going basis.
Tomek, you still have a -1 on this review. Please see my comment and verify that issue.
Created attachment 233295 [details] screenshot with the error On the review I said: "Not sure if this is supposed to be fixed by the patch but I still get an error saying "Cannot Fetch. Try re-synchronizing the review task. If that fails, there may be a problem with your repository connection." if I try to fetch a patch set while the review is being retrieved." And I'm still able to reproduce it. It doesn't happen every time, I guess I had to try 3 reviews to see it. Here are the steps: 1. Open a review in editor 2. Make sure a job retrieving review is running 3. Press Fetch If I close the error dialog and press Fetch again it works as expected.
(In reply to comment #6) > If I close the error dialog and press Fetch again it works as expected. Thanks. I'll take a look at this but prob. not until tmrw.
(In reply to comment #6) > Created attachment 233295 [details] > And I'm still able to reproduce it. It doesn't happen every time, I guess I had > to try 3 reviews to see it. Here are the steps: Hmm..I tried it a bunch of times and still no luck. Perhaps because I'm closer to my test server.. but even if I click when the pathct set contents aren't listed, it doesn't happen. At this point, I'm inclined to get this change in and open another bug for your issue. Does that make sense to you?
(In reply to comment #8) > Does that make sense to you? Fine with me, as long as it's going to be targeted for 2.0.1. In the meantime, maybe we should add some tracing to track the culprit more easily? I also noticed that for some reviews the "Retrieving Review XXX" and "Retrieving Review XXX, Patch Set YYY" jobs are ran, even when the patch set is already there. I found at least one review where "Synchronize to retrieve task data" msg stuck forever and the "Retrieving Review XXX" job wasn't fired. Comparing two patches sometimes takes forever = doesn't work. It either opens instantly or never. Luckily, the job can be cancelled.
(In reply to comment #9) > Fine with me, as long as it's going to be targeted for 2.0.1. In the meantime, > maybe we should add some tracing to track the culprit more easily? Interesting idea. Do you have suggestions about how to implement that? > I also noticed that for some reviews the "Retrieving Review XXX" and "Retrieving > Review XXX, Patch Set YYY" jobs are ran, even when the patch set is already > there. Well, they will be, when you have refreshed the task. > I found at least one review where "Synchronize to retrieve task data" msg stuck > forever and the "Retrieving Review XXX" job wasn't fired. If you find that case, please record it. > Comparing two patches sometimes takes forever = doesn't work. It either opens > instantly or never. Luckily, the job can be cancelled. Yes, I'm not sure if that's something that is happening on the backend or now. It would be good to isolate that.
(In reply to comment #9) > (In reply to comment #8) > > Does that make sense to you? > > Fine with me, as long as it's going to be targeted for 2.0.1. bug 412782: Intermittent fetching issues.
(In reply to comment #10) > > I found at least one review where "Synchronize to retrieve task data" msg stuck > > forever and the "Retrieving Review XXX" job wasn't fired. > > If you find that case, please record it. What do you mean by 'record it'? What kind of information would help you investigate this?
(In reply to comment #12) > (In reply to comment #10) > > > I found at least one review where "Synchronize to retrieve task data" msg stuck > > > forever and the "Retrieving Review XXX" job wasn't fired. > > > > If you find that case, please record it. > > What do you mean by 'record it'? What kind of information would help you > investigate this? You mentioned "one review". I was thinking that you were referring to a specific review. If so, please send me the details. Otherwise, let's see if we can find a pattern and open a bug for it. We should treat any remaining issues separately.
