Open jinnatar opened 7 years ago
I tracked down the push that makes it die, it's a link push. Comparing it to a working one there's a few peculiarities about it:
%> comm broken working
u'active'
u'awake_app_guids'
u'created'
u'direction'
u'dismissed'
u'guid'
u'iden'
u'modified'
u'receiver_email'
u'receiver_email_normalized'
u'receiver_iden'
u'sender_email'
u'sender_email_normalized'
u'sender_iden'
u'sender_name'
u'source_device_iden'
u'target_device_iden'
u'title'
u'type'
u'url'
So the broken one has only these fields set: u'active' u'created' u'direction' u'dismissed' u'iden' u'modified' u'receiver_email' u'receiver_email_normalized' u'receiver_iden' u'sender_email' u'sender_email_normalized' u'sender_iden' u'sender_name' u'target_device_iden' u'title' u'type'
So missing:
I'm not too good with Python but seems to me like this bit here: https://github.com/kstep/pushybullet/blob/e457bc9a37ae92ba88f75d8bab17baae0c6f837d/pushybullet.py#L1100 could be a bit more robust to catch this kind of brokenness.
Running latest HEAD the api.pushes() interface crashes:
This is my "backlog" loop so the relevant code is very simple:
Normally the loop handles url and file type pushes and even does so successfully if I push new items into the queue. But eventually it always crashes and burns like this. So almost 100% sure there's something funny in the queue that kills processing, I just can't see it from anywhere.
The same issue repeats with the pb client:
So, at a minimum I'd say some basic exception handling needs to be implemented to catch some whiff of the push causing the meltdown, and then can think about working around said meltdown.