After wake-up from "suspend mode" of my laptop, I need to re-enable prpltwtr

[GoogleCodeExporter]

Client (Pidgin, finch, empathy, etc): Pidgin
Client Version: 2.6.6
LibPurple Version: 2.6.6
PrplTwtr Version: 0.5.2
Operating System: Ubuntu 9.10

When I return from "suspend mode" on my laptop, pidgin reconnects the
various protocols I use, but I need to re-enable prpltwtr.

I've used OAuth for a while, but then I regularly had to re-enter a new
OAuth key provided by twitter. Now I use the https option.

(It's just a minor inconvenience, a simple click on "re-enable" makes it
work again with the https option.)

Original issue reported on code.google.com by rolfkl...@gmail.com on 28 Apr 2010 at 7:53

[GoogleCodeExporter]

There are really two issues here:
OAuth, which I think is fixed.
Disabled, which is a real problem. I will look into the second; if the first 
occurs, please comment here

Original comment by mikeage on 14 Feb 2011 at 6:40

• Changed state: Started

[GoogleCodeExporter]

I just pushed a change to the source which should fix this.

Are you able to test it?

Original comment by mikeage on 16 Feb 2011 at 9:14

[GoogleCodeExporter]

I'll check on my old laptop (something to do the coming weekend, I think)

(my new Sony laptop reboots when trying to resume after suspend...)

Original comment by rolfkl...@gmail.com on 16 Feb 2011 at 3:21

[GoogleCodeExporter]

Great, thanks. The issue appears to have been that all failed connections were 
treated as authentication failures, which don't automatically retry. I marked 
the server ones as network failures, which are treated as temporary, and 
automatically retry. It worked on my tests here [and I suffered from this a 
_lot_, since I work over a flaky VPN]. I hope it should work for you also.

Original comment by mikeage on 16 Feb 2011 at 3:40

[GoogleCodeExporter]

It turned into a weekend later... I just downloaded and compiled 0.6.3, but 
still the same thing: when coming back from resume, it says "Error verifying 
credentials". 

I've looked at the debug output for a pattern. I also tried to use the 
NetworkManager to disconnect (Pidgin indicates it's waiting for a network 
connection) and then reconnect: it works fine then. The main difference I can 
find between a suspend-cycle and a manual disconnect-connect, is the state 
changes of the NetworkManager:

"Got StateChange from NetworkManager: 1" only appears on suspend/resume, 
indicating the device is asleep (rather than just disconnected): 
http://projects.gnome.org/NetworkManager/developers/spec.html#type-NM_STATE

So I can now reproduce the behaviour on my new laptop by manually putting the 
network devices to sleep and waking them up again:

    nmcli nm sleep
    nmcli nm wakeup

This results in the same "Error verifying credentials" for a while, but on my 
new laptop (64-bit Ubuntu 10.10), Pidgin does reconnect after a few seconds. It 
does not seem to try again on my previous laptop (32-bit Ubuntu 10.04). Same 
version of Pidgin (2.7.3), but on my previous laptop I experimented with Pidgin 
plugins over the years, so it may very well be some dependency or error 
elsewhere.

It appears to work well on my new laptop, so I suggest you close this ticket -- 
unless you have a desire to continue debugging this :-)

Original comment by rolfkl...@gmail.com on 27 Feb 2011 at 3:17

[GoogleCodeExporter]

I don't mind leaving it open if you think there's something else to investigate.

If you want, run it in debug mode (pidgin -d 2>&1) and look at the log for the 
string "error verify credentials" [yes, I know it should say "verifying"]. If 
you can tell me what the message displayed after that, I can see if I'm 
mis-identifying a recoverable error as non-recoverable.

Original comment by mikeage on 27 Feb 2011 at 3:49

[GoogleCodeExporter]

Here's part of the log I had -- it looks like the network connects (state 3), 
prpltwtr starts reconnecting, then the network device is disconnected (state 
4), the verify error happens, and the network device reconnects (states 2, 3). 
The message on verification is (null), and no further automatic reconnect 
happens.

(14:37:48) network: Got StateChange from NetworkManager: 3.
(14:37:48) network: running DNS query for STUN server
(14:37:48) dns: DNS query for 'stunserver.org' queued
(14:37:48) autorecon: do_signon called
(14:37:48) autorecon: calling purple_account_connect
(14:37:48) account: Connecting to account rolfkleef.
(14:37:48) connection: Connecting. gc = 0x8883e20
(14:37:48) prpl-twitter: logging in rolfkleef
(14:37:48) prpl-twitter: Sending GET request to: 
http://api.twitter.com/1/account/verify_credentials.xml ? [xxxx]
(14:37:48) util: requesting to fetch a URL
(14:37:48) dns: DNS query for 'api.twitter.com' queued
(14:37:48) autorecon: done calling purple_account_connect
(14:37:48) dns: Wait for DNS child 13999 failed: No child processes
(14:37:48) dns: Created new DNS child 14460, there are now 1 children.
(14:37:48) dns: Successfully sent DNS request to child 14460
(14:37:48) dns: Created new DNS child 14464, there are now 2 children.
(14:37:48) dns: Successfully sent DNS request to child 14464
(14:37:48) network: Got StateChange from NetworkManager: 4.
(14:37:48) account: Disconnecting account rolfkleef (0x8596918)
(14:37:48) connection: Disconnecting connection 0x8883e20
(14:37:48) prpl-twitter: Freeing requestor
(14:37:48) prpl-twitter: Error verifying credentials. Error type 5: (null)
(14:37:48) connection: Connection error on 0x8883e20 (reason: 2 description: 
Error verifying credentials)
(14:37:48) prpl-twitter: post_failed called for account rolfkleef, error 5, 
message 
(14:37:48) prpl-twitter: twitter_conv_icon_remove_conversation_conv_icons conv 
Search: android
(14:37:48) prpl-twitter: twitter_conv_icon_remove_conversation_conv_icons conv 
Timeline: Home
(14:37:49) connection: Destroying connection 0x8883e20
(14:37:49) dns: Got response for 'stunserver.org'
(14:37:49) dnsquery: Error resolving stunserver.org:
Name or service not known
(14:37:49) network: lookup of IP address failed: Error resolving stunserver.org:
Name or service not known
(14:37:51) network: Got StateChange from NetworkManager: 2.
(14:37:54) util: Writing file accounts.xml to directory /home/rolf/.purple
(14:37:54) util: Writing file /home/rolf/.purple/accounts.xml
(14:37:55) network: Got StateChange from NetworkManager: 3.
(14:37:55) network: running DNS query for STUN server

Original comment by rolfkl...@gmail.com on 27 Feb 2011 at 6:20

[GoogleCodeExporter]

Thanks. 

It appears that twitter_close() is being called, and that cancels the 
requestor. As such, it doesn't try to reconnect. That makes sense.

Do other plugins reconnect in this case?

Let me look and see how/why they do it.

Original comment by mikeage on 27 Feb 2011 at 6:28