Ticket #24 (closed defect: fixed)

Opened 18 months ago

Last modified 16 months ago

Blocking/unblocking contacts too fast kills them

Reported by: dx Owned by: dx
Priority: critical Milestone: 1.0
Component: emesenelib Version:
Keywords: MESSAGE Cc: Ny

Description

IMPORTANT NOTE: DON'T TRY THIS IF YOU DON'T KNOW HOW TO FIX IT. Before testing, activate the /eval plugin, and have a conversation window opened. You have to know how to add/remove users manually (/eval) if something goes wrong.

If you block a contact and don't wait until stage 1 is finished, this happens:

### dx blocks someone
>>> RML 20 68
<ml><d n="hotmail.com"><c n="someone" t="1" l="2" /></d></ml>
>>> ADL 21 68
<ml><d n="hotmail.com"><c n="someone" t="1" l="4" /></d></ml>
<<< RML 20 OK
<<< ADL 21 OK
### dx unblocks someone
>>> RML 22 68
<ml><d n="hotmail.com"><c n="someone" t="1" l="4" /></d></ml>
>>> ADL 23 68
<ml><d n="hotmail.com"><c n="someone" t="1" l="2" /></d></ml>
### block soap request 0
block user (stage 0): (200, 'OK')
### unblock DL replies
<<< RML 22 OK
<<< ADL 23 OK
### unblock soap request 0 (block 1 not sent)
unblock user (stage 0): (500, 'Internal Server Error')
Traceback (most recent call last):
  File "Controller.py", line 351, in process
    self.msn.process()
  File "/home/dx/esevene/emesenelib/core.py", line 563, in process
    '''
  File "/home/dx/esevene/emesenelib/SoapManager.py", line 51, in process
    response.getCallback()( response, *response.getArgs() )
  File "/home/dx/esevene/emesenelib/core.py", line 1026, in onUserUnblocked
    self.emit( 'user-list-change' )
emesenelib.core.SoapError: 'User could not be unblocked (stage 0)' (500, 'Internal Server Error'): u'Member does not exist '

After that (fatal) error, emesene execution loop stops. If you don't /resurrect it, the blocked contact won't appear again in your contact list, and you'll be unable to add it again (using the GUI, because /eval can help you)

Remember to fix:

  • Disable the contact management options until the operation is finished
  • Handle the exceptions on soap errors
  • Do not handle the exceptions in Controller.py:351 (self.msn.process()), or make it give a good visual feedback. These kind of exceptions are always bugs, and they need the attention from the user.

Attachments

block_unblock.txt (15.6 kB) - added by dx 18 months ago.
Blocking and unblocking a contact with WLM. Plain text export of wireshark capture with filter: (ssl.handshake.type == 1) || (msnms && (msnms contains RML || msnms contains ADL))
block_unblock.pcap (22.3 kB) - added by dx 18 months ago.
Blocking and unblocking a contact with WLM. The same thing as above but with pcap format

Change History

Changed 18 months ago by dx

Blocking and unblocking a contact with WLM. Plain text export of wireshark capture with filter: (ssl.handshake.type == 1) (msnms && (msnms contains RML msnms contains ADL))

Changed 18 months ago by dx

Blocking and unblocking a contact with WLM. The same thing as above but with pcap format

Changed 18 months ago by marianoguerra

maybe we should have a SoapRequestInProgress? boolean or something like that?

so we dont start to make conflictive or repeated SoapRequests? at the same time?

Changed 18 months ago by dx

In emesenelib or in the client? If we add it to emesenelib, new messages should be queued (yes.. some people like blocking/unblocking..)

We could also check the local contacts list status, if it's possible to block/unblock/move that user...

Changed 17 months ago by dx

  • owner changed from somebody to dx
  • status changed from new to assigned

Ok, i'll fix this myself. Some ideas:

  1. "SoapRequestInProgress?" will be just "locks" (in ContactData?). If a lock is set, contact management is disabled for that user.
  2. It won't raise exceptions, and it will try to fix the situation (TODOs here)
  3. Queue for this means hell for resources.

Changed 17 months ago by dx

  • status changed from assigned to closed
  • resolution set to fixed

done, 666

Add/Change #24 (Blocking/unblocking contacts too fast kills them)

Author



Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.