Exception after removing torrent

[gazpachoking]

Unhandled exception can occur after removing a torrent:

Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "C:\Python26\lib\site-packages\twisted\protocols\policies.py", line 118, in dataReceived
    self.wrappedProtocol.dataReceived(data)
  File "C:\Users\Chase\pycharm projects\deluge\deluge\ui\client.py", line 183, in dataReceived
    d.callback(request[2])
  File "C:\Python26\lib\site-packages\twisted\internet\defer.py", line 368, in callback
    self._startRunCallbacks(result)
  File "C:\Python26\lib\site-packages\twisted\internet\defer.py", line 464, in _startRunCallbacks
    self._runCallbacks()
--- <exception caught here> ---
  File "C:\Python26\lib\site-packages\twisted\internet\defer.py", line 551, in _runCallbacks
    current.result = callback(current.result, *args, **kw)
  File "C:\Users\Chase\pycharm projects\deluge\deluge\ui\sessionproxy.py", line 191, in on_status
    return self.create_status_dict(torrent_ids, keys)
  File "C:\Users\Chase\pycharm projects\deluge\deluge\ui\sessionproxy.py", line 106, in create_status_dict
    sd[torrent_id] = dict([(x, y) for x, y in self.torrents[torrent_id][1].iteritems() if x in keys])
exceptions.KeyError: '5ff038bbac132fe3b9b4e2f38293d548ed5b853d'

[gazpachoking]

We could just check for the existence of the hash or catch this exception, I'd like to check what is calling this if we can fix it at a higher level though.

[Cas]

It seems like a race condition between one (or same?) ui deleting and another's regular call to get_torrents_status still containing the deleted torrent id.

This should prevent the error:

deluge/ui/sessionproxy.py

@@ -102 +102 @@
         """
         sd = {}
         for torrent_id in torrent_ids:
-            if keys:
-                sd[torrent_id] = dict([(x, y) for x, y in self.torrents[torrent_id][1].iteritems() if x in keys])
-            else:
-                sd[torrent_id] = dict(self.torrents[torrent_id][1])
+            if torrent_id in self.torrents:
+                if keys:
+                    sd[torrent_id] = dict([(x, y) for x, y in self.torrents[torrent_id][1].iteritems() if x in keys])
+                else:
+                    sd[torrent_id] = dict(self.torrents[torrent_id][1])
 
         return sd
 
@@ -194 +195 @@
             to_fetch = []
             t = time.time()
             for torrent_id in torrent_ids:
-                torrent = self.torrents[torrent_id]
-                if t - torrent[0] > self.cache_time:
-                    to_fetch.append(torrent_id)
-                else:
-                    # We need to check if a key is expired
-                    for key in keys:
-                        if t - self.cache_times[torrent_id].get(key, 0.0) > self.cache_time:
-                            to_fetch.append(torrent_id)
-                            break
+                if torrent_id in self.torrents:
+                    torrent = self.torrents[torrent_id]
+                    if t - torrent[0] > self.cache_time:
+                        to_fetch.append(torrent_id)
+                    else:
+                        # We need to check if a key is expired
+                        for key in keys:
+                            if t - self.cache_times[torrent_id].get(key, 0.0) > self.cache_time:
+                                to_fetch.append(torrent_id)
+                                break
 
             return to_fetch
         #-----------------------------------------------------------------------

[Cas]

When deleting a torrent there is a delay before session proxy receives the torrent_removed event so a call to get_torrents_status with the list of its known torrents including recently deleted is possible which generates a keyerror in torrentmanager.getitem (#2224), sessionproxy.create_status_dict or sessionproxy.get_torrents_status.on_status depending on the timings.

I think this fix should account for all these outcomes: ​https://github.com/cas--/Deluge/compare/Bug;2205;ExceptionsRemovingTorrents

[Cas]

Turns out this was already fixed in git master.

1.3-stable commits: ​c741e127b925e, ​b5ea33e50666