[Buildbot-devel] problem with email notifications

[Brian Warner]

> class MyLookup:
>      from buildbot import interfaces
>      if implements:
>          implements( interfaces.IEmailLookup )
>      else:
>          __implements__ = interfaces.IEmailLookup,
>      def getAddress( self, user ):
>          addresses = {    'user1' : user1 at xxx.com',
>                          'user2' : 'user2 at xxx.com',
>                          'stephend' : 'stephend at xxx.com'
>                      }
> 
>          d = defer.Deferred()
> 
>          # if the user name isn't in the list, email won't get sent to
>          # that user
>          d.callback( addresses[user] )
>          return d

You may want to use 'addresses.get(user)' if you want to ignore unknown
users. addresses['unknown'] raises a KeyError, addresses.get('unknown')
returns None, addresses.get('unknown', 'DEFAULT') returns 'DEFAULT'. Given
the DeferredList, I'm not actually positive what the behavior would be in the
face of an error. It's possible that it would ignore the lookup error, or
that it might try to use the resulting Failure object as an email address,
which would result in a pretty mangled To: header.

> Why is there all the deferred stuff in the lookup method?  Are you  
> assuming it could take a long time or something?  Just wondering.

Yup, I've learned to avoid premature synchronization. If someone writes a
Lookup class that has to do something slow (say, doing an LDAP lookup for the
address, or querying some rolodex-like web page), then if getAddress() is
defined to return immediately, they're out of luck. A lot of lookup-style
interfaces in Twisted are defined this way. Blocking code is a no-no, so you
have to be flexible enough to not impose immediacy upon anybody.

However, the use of maybeDeferred() in the call to getAddress() means that
you can ignore all that. Just have your getAddress do:

    return addresses.get(user)

But, apart from the unknown-user case, your code is correct.. that's the
right way to use a deferred that is ready immediately. (There is a
convenience function that lets you spell 'd = defer.Deferred();
d.callback(result)' as 'd = defer.succeed(result)', but it behaves exactly
the same way).

So if the extra users aren't getting the messages, I'd either suspect the
unknown-user issue, or that the build isn't getting set up with the right
"interested users" in the first place. Try adding something like:

 log.msg("Interested users: %s" % (build.getInterestedUsers(),))

to MailNotifier.buildMessage() and make sure the blamelist at least has the
right names on it. Perhaps it's possible that something silly in the Change
processing chain changed and broke blame badly.

alliteratively,
 -Brian