Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-16332

Leading and trailing underscores are added to commiters email address, unable to send build notification

      Jenkins email-ext plugin fails to send email, the error is

      Failed to create e-mail address for _developer1@xxx.net_
      Failed to create e-mail address for _developer2@xxx.net_
      Failed to create e-mail address for _developer1@xxx.net_
      Failed to create e-mail address for _developer1@xxx.net_

      (Names and domain are changed)

      Jan 13, 2013 7:15:56 PM hudson.plugins.emailext.ExtendedEmailPublisher addAddressesFromRecipientList
      WARNING: Could not create email address.
      javax.mail.internet.AddressException: Domain contains illegal character in string ``_developer1@xxx.net_''
      at javax.mail.internet.InternetAddress.checkAddress(InternetAddress.java:1269)
      at javax.mail.internet.InternetAddress.parse(InternetAddress.java:1091)
      at javax.mail.internet.InternetAddress.parse(InternetAddress.java:633)
      at javax.mail.internet.InternetAddress.<init>(InternetAddress.java:111)
      at hudson.plugins.emailext.EmailRecipientUtils.convertRecipientString(EmailRecipientUtils.java:60)
      at hudson.plugins.emailext.ExtendedEmailPublisher.addAddressesFromRecipientList(ExtendedEmailPublisher.java:687)
      at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:508)
      at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:297)
      at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:289)
      at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:249)
      at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
      at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810)
      at hudson.model.AbstractBuild$AbstractBuildExecution.perJan 13, 2013 7:15:56 PM hudson.plugins.emailext.ExtendedEmailPublisher addAddressesFromRecipientList
      WARNING: Could not create email address.
      javax.mail.internet.AddressException: Domain contains illegal character in string ``_developer1@xxx.net_''
      at javax.mail.internet.InternetAddress.checkAddress(InternetAddress.java:1269)
      at javax.mail.internet.InternetAddress.parse(InternetAddress.java:1091)
      at javax.mail.internet.InternetAddress.parse(InternetAddress.java:633)
      at javax.mail.internet.InternetAddress.<init>(InternetAddress.java:111)
      at hudson.plugins.emailext.EmailRecipientUtils.convertRecipientString(EmailRecipientUtils.java:60)
      at hudson.plugins.emailext.ExtendedEmailPublisher.addAddressesFromRecipientList(ExtendedEmailPublisher.java:687)
      at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:508)
      at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:297)
      at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:289)
      at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:249)
      at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
      at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810)
      at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:785)
      at hudson.model.Build$BuildExecution.cleanUp(Build.java:192)
      at hudson.model.Run.execute(Run.java:1587)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:236)formAllBuildSteps(AbstractBuild.java:785)
      at hudson.model.Build$BuildExecution.cleanUp(Build.java:192)
      at hudson.model.Run.execute(Run.java:1587)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:236)

      First I thought is the problem is in email-ext plugin, but when I went to "Changes" tab and opened the page

      http://host/jenkins/user/Developer%201%20__developer1@xxx.net_/
      (hostname changed)

      it showed

      Jenkins User Id: Developer 1 _developer1@xxx.net_

      For unknown reason Jenkins adds a leading and trailing underscore to email address

      Environment
      Jenkins ver. 1.498
      Jenkins Mercurial plugin 1.42
      Jenkins Email Extension Plugin 2.25
      Mercurial Distributed SCM (version 1.4.3)
      Ubuntu 10.04.4 LTS
      Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
      Java HotSpot(TM) 64-Bit Server VM (build 20.7-b02, mixed mode)

      We have a build cluster with a master and two slaves, this problem happened on the slave machine.

      When I type hg log on Jenkins job's workspace, then all changesets have
      correct email address without underscores, so it is not Mercurial configuration problem.

          [JENKINS-16332] Leading and trailing underscores are added to commiters email address, unable to send build notification

          Jesse Glick added a comment -

          Still working on reproducing from scratch. I think I may see what the issue is. If I am right, it is a bug in core as I suspected on Dec 19.

          Jesse Glick added a comment - Still working on reproducing from scratch. I think I may see what the issue is. If I am right, it is a bug in core as I suspected on Dec 19.

          Jesse Glick added a comment -

          OK, finally reproduced. The mentioned line 729 is innocent, and really AbstractBuild as a whole is doing nothing wrong; nor, as far as I can tell, are the Mailer or Mercurial plugins.

          The problem (as I surmised on Sep 16) is in User itself. When you run a build that fails, and it has a changelog mentioning at least one user with full name & email address who does not yet have any permanent record in $JENKINS_HOME/users/$id/config.xml, the build stores a culprits field listing the user’s ID, which correctly includes underscores. So long as Jenkins remains running, the loaded User object is fine, and mailing would work. However if you restart Jenkins, and then run a new build that again fails, but with no changelog this time, getCulprits inherits the culprits list from the previous build. This time User.get(id) is called and since there is no persistent record for that user, there is no way of reconstructing the proper fullName—we only have the sanitized ID. Therefore the User is constructed with a bogus fullName and mailing fails.

          Looking into a fix.

          Jesse Glick added a comment - OK, finally reproduced. The mentioned line 729 is innocent, and really AbstractBuild as a whole is doing nothing wrong; nor, as far as I can tell, are the Mailer or Mercurial plugins. The problem (as I surmised on Sep 16) is in User itself. When you run a build that fails, and it has a changelog mentioning at least one user with full name & email address who does not yet have any permanent record in $JENKINS_HOME/users/$id/config.xml , the build stores a culprits field listing the user’s ID, which correctly includes underscores. So long as Jenkins remains running, the loaded User object is fine, and mailing would work. However if you restart Jenkins, and then run a new build that again fails, but with no changelog this time, getCulprits inherits the culprits list from the previous build. This time User.get(id) is called and since there is no persistent record for that user, there is no way of reconstructing the proper fullName —we only have the sanitized ID. Therefore the User is constructed with a bogus fullName and mailing fails. Looking into a fix.

          Alex Earl added a comment -

          Jesse, I just like to poke at these until you come up with the correct solution

          Alex Earl added a comment - Jesse, I just like to poke at these until you come up with the correct solution

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          core/src/main/java/hudson/model/User.java
          test/src/test/java/hudson/model/UserTest.java
          http://jenkins-ci.org/commit/jenkins/fdda9ca65689423794a8378c1f28faca7dffddf0
          Log:
          [FIXED JENKINS-16332] Ensure that User records are saved when the fullName is not recoverable from the id.
          Otherwise User.get(id).getFullName() after restarting Jenkins will produce the wrong result.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/model/User.java test/src/test/java/hudson/model/UserTest.java http://jenkins-ci.org/commit/jenkins/fdda9ca65689423794a8378c1f28faca7dffddf0 Log: [FIXED JENKINS-16332] Ensure that User records are saved when the fullName is not recoverable from the id. Otherwise User.get(id).getFullName() after restarting Jenkins will produce the wrong result.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3192
          [FIXED JENKINS-16332] Ensure that User records are saved when the fullName is not recoverable from the id. (Revision fdda9ca65689423794a8378c1f28faca7dffddf0)

          Result = SUCCESS
          Jesse Glick : fdda9ca65689423794a8378c1f28faca7dffddf0
          Files :

          • test/src/test/java/hudson/model/UserTest.java
          • changelog.html
          • core/src/main/java/hudson/model/User.java

          dogfood added a comment - Integrated in jenkins_main_trunk #3192 [FIXED JENKINS-16332] Ensure that User records are saved when the fullName is not recoverable from the id. (Revision fdda9ca65689423794a8378c1f28faca7dffddf0) Result = SUCCESS Jesse Glick : fdda9ca65689423794a8378c1f28faca7dffddf0 Files : test/src/test/java/hudson/model/UserTest.java changelog.html core/src/main/java/hudson/model/User.java

          cowwoc added a comment -

          Jesse,

          Will this fix jobs where malformed culprits were being copied from earlier builds, or do we need to manually "flush" the job history somehow?

          cowwoc added a comment - Jesse, Will this fix jobs where malformed culprits were being copied from earlier builds, or do we need to manually "flush" the job history somehow?

          Jesse Glick added a comment -

          This fix will not handle all cases involving historical records. If a new build is run after upgrade whose changelog mentions the given committer’s full name, that name will be properly registered and you should not see the problem for that user again. The main problem I can foresee is a build which was failing at the time of upgrade, and continues to fail without new changes being committed (to that or other jobs developed by the same people), and is using an email trigger configured to repeatedly send mail for every unstable build.

          Again there are no “malformed” culprits fields here. The culprits list is correct; the problem only arises when the culprits list contains the only record of a given user in the system. You ought to be able to work around the problem for a given user by visiting that user’s page as hyperlinked from a changelog (logged in as an administrator), and explicitly setting a full name (and/or email address).

          Jesse Glick added a comment - This fix will not handle all cases involving historical records. If a new build is run after upgrade whose changelog mentions the given committer’s full name, that name will be properly registered and you should not see the problem for that user again. The main problem I can foresee is a build which was failing at the time of upgrade, and continues to fail without new changes being committed (to that or other jobs developed by the same people), and is using an email trigger configured to repeatedly send mail for every unstable build. Again there are no “malformed” culprits fields here. The culprits list is correct; the problem only arises when the culprits list contains the only record of a given user in the system. You ought to be able to work around the problem for a given user by visiting that user’s page as hyperlinked from a changelog (logged in as an administrator), and explicitly setting a full name (and/or email address).

          cowwoc added a comment -

          I see. So just to make sure I understand correctly:

          Until a user makes a new commit, any existing jobs will keep on using the incorrect email address. Once a user makes a new commit, his email address will get corrected system-wide across all jobs. Alternatively, deleting the contents of the "builds" directory will remove all changelogs and force re-evaluation of the email address.

          Is that correct?

          cowwoc added a comment - I see. So just to make sure I understand correctly: Until a user makes a new commit, any existing jobs will keep on using the incorrect email address. Once a user makes a new commit, his email address will get corrected system-wide across all jobs. Alternatively, deleting the contents of the "builds" directory will remove all changelogs and force re-evaluation of the email address. Is that correct?

          Jesse Glick added a comment -

          Until a user makes a new commit, any existing jobs will keep on using the incorrect email address. Once a user makes a new commit, his email address will get corrected system-wide across all jobs.

          Right. You can simply look in $JENKINS_HOME/users/ to see whether the user has been defined or not.

          deleting the contents of the "builds" directory will remove all changelogs and force re-evaluation of the email address.

          No. If you deleted all historical builds, then either the next build has commits from the relevant user(s), in which case their email addresses will be recorded; or it does not, in which case the culprits list for that build will simply be empty and no email will be sent (unless you have an unconditional recipient configured in the job). In the former case, deleting the old build records does not improve your situation at all. In the latter case, deleting them could make the new build’s status be “unstable” due to test failures or whatever, rather than “failed” due to an attempt to send mail to bogus addresses, but the email addresses of users mentioned in those old builds would still be missing.

          Jesse Glick added a comment - Until a user makes a new commit, any existing jobs will keep on using the incorrect email address. Once a user makes a new commit, his email address will get corrected system-wide across all jobs. Right. You can simply look in $JENKINS_HOME/users/ to see whether the user has been defined or not. deleting the contents of the "builds" directory will remove all changelogs and force re-evaluation of the email address. No. If you deleted all historical builds, then either the next build has commits from the relevant user(s), in which case their email addresses will be recorded; or it does not, in which case the culprits list for that build will simply be empty and no email will be sent (unless you have an unconditional recipient configured in the job). In the former case, deleting the old build records does not improve your situation at all. In the latter case, deleting them could make the new build’s status be “unstable” due to test failures or whatever, rather than “failed” due to an attempt to send mail to bogus addresses, but the email addresses of users mentioned in those old builds would still be missing.

          Fixed in 1.554. No need to backport.

          Oliver Gondža added a comment - Fixed in 1.554. No need to backport.

            jglick Jesse Glick
            sgr Sergey Grigoriev
            Votes:
            6 Vote for this issue
            Watchers:
            20 Start watching this issue

              Created:
              Updated:
              Resolved: