The post function incorrectly attempts to store the changes made to the issue object to the database at the end of processing. This creates a race condition when the function is being used in the Create Issue step of a workflow (the initial step), placed before the "Creates the issue originally" function (IssueCreateFunction). When this is the case, the issue object is persisted to the database for the first time by AssignToLeadFunction instead of IssueCreateFunction. This leads to some information not being persisted (workflow_id), which in turn causes the NullPointerException.

Post functions which modify issue fields are supposed to defer the responsibility of persisting changes to the "store issue to database" or "create issue originally" post functions, so that the update for all fields can occur in a single post function, resulting in fewer database calls. However, the fix for this issue is not simply to remove the "store" call from the AssignToLeadFunction, as this would change the behaviour of the post function when it occurs after the "store issue to database" post functions (i.e. it would no longer work). So, the fix is to modify the AssignToLeadFunction so that it does not prematurely persist a new issue to the database; but if the issue already exists in the database, it will call store as before.

If you are using AssignToLeadFunction in a transition, and it is placed after the "store issue to database" post function, then for correctness we recommend you modify your workflows so that the function is placed correctly before the relevant "store issue to database" post function. For more information, please read the "Adding a post function" section in the JIRA workflow transitions documentation.

Note: post functions need to be standardised in how they deal with issue persistence, and this needs to be documented.