[GUI] QT shutdown is blocked if called before gettxoutsetinfo is finished #13217

1. 
   ghost commented at 4:31 pm on May 11, 2018: none

   Steps to reproduce:

   1. Open QT console.
   2. Run gettxoutsetinfo.
   3. Exit the debug window (no blocking) -> exit the program (will block).

   This is what is shown on Windows (10) for several minutes: https://i.imgur.com/AyexgkC.png

2. 
   promag commented at 4:34 pm on May 11, 2018: member

   The same would happen with other long calls.
3. 
   ghost commented at 4:36 pm on May 11, 2018: none

   It’s similar to how rescan used to be uninterruptible. Is this perhaps already documented somewhere ?
4. 
   jonasschnelli commented at 7:39 am on May 14, 2018: contributor

   It would be easy fixable, though I don’t see a big need for allowing shutdown during gettxoutsetinfo. @laudaa: can you elaborate more more about the use-case and why it would be required to allow a shutdown at this point?
5. 
   ghost commented at 8:08 am on May 14, 2018: none

   @jonasschnelli As promag as mentioned, this would occur for other long calls as well (although I’m not sure which all of these would be; gettxoutsetinfo is just the one that I encountered this with and it’s notably long at ~5 minutes on the system that I’ve tried it). The very least that could be done is a proper exiting window informing the user that a call is still in progress (or at the very least document this somewhere if it isn’t already?). The way that it is now (see image) it looks like the software isn’t working anymore (“Not responding”) which will probably result in users trying to forcefully close it. This might lead to other unexpected issues (e.g., need for a reindex?).
6. 
   promag commented at 8:23 am on May 14, 2018: member

   Agree, either it should interrupt the call or inform the user to wait. Otherwise he may force quit.
7. jonasschnelli added the label RPC/REST/ZMQ on May 16, 2018
8. jonasschnelli added the label good first issue on May 16, 2018
9. 
   LeandroRocha84 commented at 7:08 am on July 16, 2018: none

   Console commands run in a separate thread (RPCExecutor) but waiting for that thread to finish takes place in the main thread, causing the GUI to become unresponsive during shutdown for long running calls.
10. 
    LeandroRocha84 commented at 7:35 am on July 16, 2018: none

    I’ve created the PR #13674 to address this issue. Any feedback is greatly appreciated.
11. MarcoFalke removed the label good first issue on May 22, 2020
12. 
    MarcoFalke commented at 8:11 pm on May 22, 2020: member

    This is an issue for the GUI and the RPC. The RPC part is fixed in #19056
13. 
    MarcoFalke commented at 11:40 am on May 23, 2020: member

    The GUI part is fixed in #17659
14. MarcoFalke added the label GUI on May 23, 2020
15. MarcoFalke referenced this in commit 13397dc78f on May 26, 2020
16. sidhujag referenced this in commit 407a8be958 on May 27, 2020
17. 
    fanquake commented at 6:49 am on August 14, 2020: member

    Given that this issue is now gui-only (RPC half fixed in #19056). I’ve moved it over to the GUI repo.
18. fanquake closed this on Aug 14, 2020

    ---

19. DrahtBot locked this on Feb 15, 2022

Contributors
ghost promag jonasschnelli LeandroRocha84 MarcoFalke fanquake

Labels
GUI RPC/REST/ZMQ