While running cronscripts/flag-expired-memberships.py on staging, this exception occurred. It doesn't indicate which membership (team & member) has the bad expiration date. In theory this shouldn't happen because handleMembershipsExpiringToday() would either autorenew or expire any members without expiration dates in the future. This might have happened due to a code update on staging around that time.
It would be very helpful for flag-expired-memberships.py to provide debug info for every user expired or autorenewed. That will either require handleMembershipsExpiringToday() to return the info, or the loop could be moved out of that method, which would have the added benefit of allowing us to commit after each membership is processed.
Traceback (most recent call last):
File "/srv/staging.launchpad.net/staging/launchpad/cronscripts/flag-expired-memberships.py", line 63, in <module>
script.lock_and_run()
File "/srv/staging.launchpad.net/staging/launchpad/lib/lp/services/scripts/base.py", line 285, in lock_and_run
implicit_begin=implicit_begin, isolation=isolation)
File "/srv/staging.launchpad.net/staging/launchpad/lib/lp/services/scripts/base.py", line 243, in run
self.main()
File "/srv/staging.launchpad.net/staging/launchpad/cronscripts/flag-expired-memberships.py", line 56, in main
self.flag_expired_memberships_and_send_warnings()
File "/srv/staging.launchpad.net/staging/launchpad/cronscripts/flag-expired-memberships.py", line 45, in flag_expired_memberships_and_send_warnings
membership.sendExpirationWarningEmail()
File "/srv/staging.launchpad.net/staging/launchpad/lib/lp/registry/model/teammembership.py", line 211, in sendExpirationWarningEmail
% self.dateexpires.strftime('%Y-%m-%d'))
AssertionError: This membership's expiration date must be in the future: 2010-07-30
Ordering the memberships to be processed would make debugging output more convenient.