After update JIRA to 6.4.13, I got Indexing completed with 1 error

[carol.li]

Hi all, 

I'm trying to upgrade our JIRA from 6.3.6 to 6.4.13,  I have already run the upgrade in our test server, and everything is working good. But during I upgrade our production one, after the upgrade process is finished, the JIRA website is not able to access, and it says the indexing completed with 1 error. I followed the debugging process in https://confluence.atlassian.com/jirakb/indexing-failed-after-jira-application-upgrade-with-reindex-all-failed-error-429917142.html, 

In cause 3: SELECT * FROM jiraissue WHERE assignee IN (SELECT user_name FROM cwd_user WHERE active = '0'); 

I got bunch of output, it has 83 rows, so I can't past it to here, but the output like below:

                                                                                                                                                                                                                | NULL        | 3        | 1          | 5           | 2013-09-07 00:44:01 | 2014-03-28 08:17:33 | NULL    | 2014-03-28 08:17:33 |     0 |       1 |                 NULL |         NULL |      NULL |       16080 |     NULL |   NULL |      NULL |

| 14834 | NULL |      627 |   10105 | pcapelluto               | unassigned | pcapelluto               | 2         | task_info: proper column sorting   

In the solution 3 said: You may need to re create the accounts with the same username in the internal directory and then de-activating the new users within JIRA. There are 83 rows, I can't just update one by one user, and I can't confirm if this is the root cause? Could you please help? 

Thanks. 

[crf]

1. To start with, the query given in the knowledge base article has not been reliable since JIRA 6.0 was released and we added the ability to rename users, so the owners need to update it.  I'm not sure who owns it, but I'll try to get it fixed.  It also doesn't take the possibility of multiple user directories into account, as the user could be inactive in one directory, but active in another one where they might be found first.
2. Assuming you only have a single directory, I think that this should instead be:  SELECT DISTINCT au.lower_user_name FROM jiraissue ji INNER JOIN app_user au ON au.user_key = ji.assignee WHERE au.lower_user_name IN (SELECT lower_user_name FROM cwd_user WHERE active = '0');
3. There is absolutely no reason why JIRA shouldn't be able to index the assignee information, regardless of whether or not the user is active.  If that is what's really happening in Cause 3, then it is rather obviously a bug and should be fixed. You should open a support case and escalate that point (referencing my reply here, if you like).  My suspicion is that the knowledge base is wrong about this entirely and that the real problem is that the LDAP directory itself is inactive, not the user within it.  An inactive directory is not searched at all, so this would indeed make it impossible for JIRA to find the user.
4. 83 users or just 83 rows?  As I rewrote the query above, you should get distinct user names by themselves, which should hopefully make this easier to manage.

If all else fails, you should contact support.  These knowledge base articles are supposed to make it to where you can solve these problems without needing additional help, and if it isn't doing that job correctly, they need to know that the article is not good enough.

[crf]

Follow-up: Our support team agreed that the information previously in "Cause 3" was not valid, so they have removed it.  Please continue looking at the remaining potential causes if you like, and/or follow the link above to create a support ticket if you need their help.

[carol.li]

Hi Chris,

May I how can I avoid this issue again during my upgrading. My database server set up in an separate host. If it caused by the database, how can I solve it?

[crf]

I would suggest:

1. Check though the other possibilities listed in the knowledge base article.
2. If that does not help, then you should contact support for additional help.

Our support team is likely to be in a better position to help you identify and correct problems with your database than I would be.