Community
Participate
Working Groups
1. Clone a repository 2. You'll get an intermediate auth fail error (this is bug 347054) 3. Clone completes. 4. Now the operations page shows two things in the list, the auth fail, and the successful result. 5. click on "remove completed" 6. Now the list only shows the auth fail. 7. If you try to delete the auth fail, you'll get an error 500 such as DELETE http://orion.eclipse.org/task/id/QH2u8zBBABEQAdSauCJ4HQ 500 (Server Error) However if you reload the page, the ghost task will disappear. Feel free to mark this a dup of bug 347054 if this is just a problem with the intermediate auth fail. However I thought maybe it's a more general problem with intermediate errors reported on tasks that eventually complete.
Created attachment 209634 [details] screenshot You can replicate this with any authenticating git operation (not just clone). Here's a screenshot after a pull.
This is a problem with synchronization of operations page with the server. This operations was in fact deleted, but somehow information about it didn't get to UI and it wasn't removed from the view. There are two problems here to solve: 1. Find out why wasn't UI notified and fix it 2. Find out why deleting not existing task returns 500, not 404, and change UI so it removes the task from the view on 404
I haven't seen this for a while, maybe some fixes in meantime fixed it. I expect some more changes in this area at Bug 365917, maybe I'll try to do those bugs together.
Updating the subject of the bug because the real problem here is that operations page did not remove the operation from the view, even when the operation was removed from server. In theory every time operation is removed from the server every longpolling request is notified and updates the operations list. Here probably the notification wasn't send.
Created attachment 211392 [details] Fixing notify about deleted. Let me remind that the problem was not that the task wasn't removed on the server, but the update was not send to the Operations site that tracks changes by longpolling. Deleted tasks are no longer stored on the server site, so we can't track them though longpolling just the same as updated operations. For the sake of longpolling I stored the last deleted operations ids so that we can notify the Operations page what tasks where removed. There where two problems here: 1. We always notified about tasks that where just removed, not about tasks that where removed from the last notification of longpolling 2. When longpolling request just came we checked if there where any changes since the last response was send, separately for updated tasks and deleted tasks. But if there where any changes in updated tasks we didn't send the deleted changes with them.
Created attachment 211406 [details] patch generated from Orion
I believe the code looks good. Can't get it to fail with a message in my list pulling multiple repos. As a project lead I +1 this for RC3 provided it is reviewed by Szymon.
Fixed with d44728975060494b8ec3cce254d0bd9b60434651.
