[IRCServices Coding] The case of the non-existant user

[Mark Hetherington]

Odd scenario, and I am not sure whether services should/could support it, 
but since it seems to be the cause of a particular chain of log messages, 
it could well be something for the FAQ if it is not something that 
should/could be supported.

A user logs on to IRC, identifies to NickServ then joins a channel that he 
has auto-op rights on. He then immediately changes nickname to another 
nickname (registered or not). Services logs the fact that a mode change was 
requested for a nonexistant user. The nicknames in the example are not 
linked. 

>From logs:

[channel]
[14:38] Damon (damon at xxxx) joined #channel.
[14:38] Nick change: Damon -> Memphis

[Services.log]
[Mar 02 14:38:59 2002] nickserv/main: Damon!damon at xxxx identified for nick 
Damon
[Mar 02 14:38:59 2002] channel: MODE #channel +o for nonexistent user Damon
[Mar 02 14:39:13 2002] nickserv/main: Memphis!damon at xxxx identified for 
nick Memphis

I have not managed to be quick enough to reproduce this 100% hence my lack 
of knowledge on whether this affects linked nicknames, but in my defence it 
is kinda late here and the timing is somewhat critical :). I suspect that 
it may apply to linked nicknames as well but assuming that services logs an 
error returned by the attempt to set a mode, I imagine the linked nick 
would trigger another test which may make mitigate the problem from a 
user's perspective.

I guess it would quite complex for services to track the user and supress 
the error as well as leading to potential circular lockup, so maybe just 
one for the FAQ. 


-- 
Mark.