Bitmessage/PyBitmessage-2024-12-03
Archived
2
0
Fork 0
Code Issues 168 Pull Requests 53 Actions Packages Projects Releases 5 Wiki Activity

Improve behavior for case where user sends multiple messages in a row but then quickly closes Bitmessage. Recover and send all of them.

Browse Source
This commit is contained in:
Jonathan Warren 2013-03-26 12:44:55 -04:00
parent 77b987c340
commit d085221219
1 changed files with 12 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
bitmessagemain.py
View File

@ -2445,6 +2445,17 @@ class singleWorker(QThread):
sqlLock.release() sqlLock.release()
for row in queryreturn: for row in queryreturn:
toripe, = row toripe, = row
#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 neededPubkeys[toripe] = 0
self.sendBroadcast() #just in case there are any proof of work tasks for Broadcasts that have yet to be sent. self.sendBroadcast() #just in case there are any proof of work tasks for Broadcasts that have yet to be sent.