From d08522121912f4f02b02b1f51aa8c5dd3b90c756 Mon Sep 17 00:00:00 2001 From: Jonathan Warren Date: Tue, 26 Mar 2013 12:44:55 -0400 Subject: [PATCH] Improve behavior for case where user sends multiple messages in a row but then quickly closes Bitmessage. Recover and send all of them. --- bitmessagemain.py | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/bitmessagemain.py b/bitmessagemain.py index 321eba42..762ee484 100755 --- a/bitmessagemain.py +++ b/bitmessagemain.py @@ -2445,7 +2445,18 @@ class singleWorker(QThread): sqlLock.release() for row in queryreturn: toripe, = row - neededPubkeys[toripe] = 0 + #It is possible for the status of a message in our sent folder (which is also our 'outbox' folder) to have a status of 'findingpubkey' even if we have the pubkey. This can + #happen if the worker thread is working on the POW for an earlier message and does not get to the message in question before the user closes Bitmessage. In this case, the + #status will still be 'findingpubkey' but Bitmessage will never have checked to see whether it actually already has the pubkey. We should therefore check here. + sqlLock.acquire() + sqlSubmitQueue.put('''SELECT hash FROM pubkeys WHERE hash=? ''') + sqlSubmitQueue.put((toripe,)) + queryreturn = sqlReturnQueue.get() + sqlLock.release() + if queryreturn != '': #If we have the pubkey then send the message otherwise put the hash in the neededPubkeys data structure so that we will pay attention to it if it comes over the wire. + self.sendMsg(toripe) + else: + neededPubkeys[toripe] = 0 self.sendBroadcast() #just in case there are any proof of work tasks for Broadcasts that have yet to be sent.