show pending status right after deletion job enqueued #955
Conversation
|
I was just unable to repro #929 after many attempts. Not the best strategy but thinking about it more, I think what was happening was that the "Select a source screen" would appear after we removed the source item from the source list before we got to |
|
I was not able to repro on master (see #929 (comment)) but we should ensure regardless of being able to reproduce that it's not possible for both views to display at the same time (by inspecting the logic is fine). I'll copy your comment there and then we can figure out in that issue if this is indeed resolved. |
| @@ -761,7 +761,7 @@ def on_delete_source_success(self, source_uuid: str) -> None: | |||
| """ | |||
| Rely on sync to delete the source locally so we know for sure it was deleted | |||
| """ | |||
| self.source_deleted.emit(source_uuid) | |||
| pass | |||
|
|
|||
| def on_delete_source_failure(self, e: Exception) -> None: | |||
| if not isinstance(e, (RequestTimeoutError, ServerConnectionError)): | |||
There was a problem hiding this comment.
I just realized that here in the source deletion failure callback we should really be setting the source widget back to its non-pending state (since the job won't get added back to the queue, and so is not pending), this can be another ticket since this is an issue on master. Since it's a rare/unexpected case I don't consider it a release blocker, but still, worth resolving.
There was a problem hiding this comment.
ah, yes, if the deletion fails due to an error other than a timeout then we should set it back to non-pending. good find!
Description
Fixes #951
Checklist
If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable: