Of course! (sorry - I should have thought of this by myself... ;) The code is attached (sorry for the ugly formatting) or given in [1] at member function 'send_mailnotification'. I have also to say, it's using 'trunk' (not re-write) and rev. 8990. The 'while' loop was introduced to do 3 re-tries (brute force) but does not help at all. My next idea would be to include the creation of the user object usr = userlib.User(pywikibot.getSite(), error_mail[0]) also into the loop, but this would also be simple trial'n'error (brute force). This is because I have no idea where the problem originates from. Is it because of wrong/old token, wrong flags, ... ?!? [1] http://toolserver.org/~drtrigon/websvn-2.3.1/filedetails.php?repname=drtrig… Greetings Am 24.07.2011 12:19, schrieb Merlijn van Deen:

Try to write a line just before the e-mail sending that checks if your bot is still logged in. Is it possible that sometimes it loses the logged-in status? -- Bináris

2011/7/24 Dr. Trigon <dr.trigon(a)surfeu.ch> No other idea at the moment. :-( -- Bináris

No - thats basically the reason why I'm asking this question here... What do you exactly mean? I have 1 bot account only. This one exists for years and mailing worked fine in the past (I had written my own mailing routine/function until I discovered the one in the framework) at least until we had to change to use SGE and cronie on the toolserver (instead of crontab)... but I don't know if this is affected by toolserver changes (as far as I understand - it should NOT) As mentioned in the past mailing from the bot and bot account worked and anyway it works even now, but just 50% of the times (roughly guessed)... In fact it worked the day before as visible from another log in [1]. (In the past I even had a "MailerBot" running - that had mailing as only job) It is a somehow frustrating thing; if I had a clue what could be the reason I would add more debugging output... And DO more debugging in the bot - but as you can see this is a rare and alternating bug which makes tracking down hard... Greetings [1] http://toolserver.org/~drtrigon/DrTrigonBot/20110723.log

aaaaahhh... this sheds light on my problem... I did the changes you suggested and now we have to wait... ;) By the way, since it could be possible to give other results between different calls (beacuse of the API), I used the same 'site' object later for the user object (just to be sure... ;) Since we are in debugging; EVERYTHING is allowed... ;) by the way, that is one of reasons why I like python that much; even if something SHOULD NOT generally be used like this, it CAN BE USED like this... ;)) This is a good hint! But since the bot runs for about 4 hrs (and on the toolserver) I'm not sure if this is applicable and how... May be with a 'screen' on TS to come back to after running the bot...? (I have to admit, I using 'pdb' not that often...) Thanks for investigationg on this!! So I did the changes mentioned in 1) to get more output. Depending on those results I will either consider 2) or have to come back to you... (should NOT be a threat... ;)) Anyway thanks a lot so far for your help, hints and time! Thanks a lot and Greetings DrTrigon

Hello, On 6 August 2011 18:55, Dr. Trigon <dr.trigon(a)surfeu.ch> wrote: First of all, sorry for the slow response. I haven't had time to look into this (and I still haven't). From the top of my head, the following (hoping someone else will be able to further assist): I *think* the list " [['user', 'bot', 'autoconfirmed','read', 'createaccount', 'edit', 'upload', 'createpage', 'createtalk','move', 'upload', 'apihighlimits'], None] " is somewhere in the bot code (wikipedia.py:5691 and further) to take as 'default' when no response (or a bogus response) is returned from the server. If not, the server might *actually* be responding with that data, in which case the server is at fault. If it *is* the default list, I think this should be fixed. It does not make much sense to me to apply a selective default list if no response is returned -- either retry or assume we can do anything. Then again, the latter means the bot would crash when trying to lock without lock rights. In essence: this needs some thought. For your problem: try calling Site.getToken(getagain=True) when you get the exception, and retry. (this calls self._load(force=True) and throug there _getUserDataOld(force=True). It's hackish, but the best I can come up with for the moment. Best, Merlijn

Hello all! When looking http://toolserver.org/~drtrigon/DrTrigonBot/20110820.log at the very end you will see: 2011/08/21 00:08:09:: Sending mail "Bot ERROR" to "DrTrigon" as notification! 2011/08/21 00:08:09:: !!! Allowed to send email: False 2011/08/21 00:08:09:: !!! Permissions: [['user', 'bot', 'autoconfirmed', 'read', 'createaccount', 'edit', 'upload', 'createpage', 'createtalk', 'move', 'upload', 'apihighlimits'], None] 2011/08/21 00:08:09:: Getting a token. 2011/08/21 00:08:09:: !!! Try getting new token: u'4ac3be5a7d488cbd4f36f5b9c3cd522d+\\' 2011/08/21 00:08:09:: Email sent. this means, the hint given: finally works! The last point is now to figure out why site.getToken sometimes is called properly and sometimes not...??? Thanks for all your help! Greetings Dr. Trigon Am 09.08.2011 21:32, schrieb Dr. Trigon: >> First of all, sorry for the slow response. I haven't had time to look >> into this (and I still haven't). From the top of my head, the following >> (hoping someone else will be able to further assist): > > No problem - in fact you responded 3 days later - compared to the delays > I produce regularly... ;)) > >> I *think* the list " [['user', 'bot', 'autoconfirmed','read', >> 'createaccount', 'edit', 'upload', 'createpage', 'createtalk','move', >> 'upload', 'apihighlimits'], None] " is somewhere in the bot code >> (wikipedia.py:5691 and further) to take as 'default' when no response >> (or a bogus response) is returned from the server. If not, the server >> might *actually* be responding with that data, in which case the server >> is at fault. > > This sounds reasonable. I had a look into those code parts and agree > with you and am also "hoping someone else will be able to further > assist"... This would be great since it looks like some core code. > As far as I can see 'Site.getToken' is called in most of the page class > member funcs such as get, put, ... so I am confused because they all > work in my code. Do you have any idea whats the initial (first) call > of 'Site.getToken' in the code - the one that seams to produce the > problems we encounter here...? > >> If it *is* the default list, I think this should be fixed. It does not >> make much sense to me to apply a selective default list if no response >> is returned -- either retry or assume we can do anything. Then again, >> the latter means the bot would crash when trying to lock without lock >> rights. >> >> In essence: this needs some thought. > > Shall I issue a bug report in tracker on sf.net? > >> there _getUserDataOld(force=True). It's hackish, but the best I can come >> up with for the moment. > > Hackish? You never looked at my bot code, did you? ;)) > > I inserted following code lines: > > if not site.isAllowed('sendemail'): > pywikibot.output(u'!!! Try getting new token: %r' % \ > (site.getToken(getagain=True),)) > > So we have to wait again... ;) (may be I have to think about how to try > to force such errors...) > > Thanks for all your support and time! > > Greetings > Dr. Trigon > > _______________________________________________ > Pywikipedia-l mailing list > Pywikipedia-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l >

Sound reasonable... But as we try to get a piece of productive software, honestly I do not feel good with terms like "Intuitively" and "reasonable"... ;) In my opinion the source of this (miss)behaviour should be tracked down. Thus I filed a bug report at sf.net: https://sourceforge.net/tracker/?func=detail&aid=3397944&group_id=9… Thanks again, greetings

But then we should file a bug report the the mw bugzilla?!? Greetings Dr. Trigon