java.lang.NumberFormatException: For input string: "false" occurs when loading user list or logging in
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
When browsing the user list, either in Jira Admin → Users, or, via Project Settings → Users and Roles, the page crashes with "Error 500", with the following stack trace being included:
java.lang.NumberFormatException: For input string: "false"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:589)
at java.lang.Long.valueOf(Long.java:803)
at com.atlassian.jira.security.login.LoginStoreImpl.getLong(LoginStoreImpl.java:143)
In addition, some users may not be able to log in, receiving the same error.
Environment
- Jira Server or Data Center
- Possibly other products also that use the Embedded Crowd libraries, such as Confluence
Diagnosis
The following query returns more than 1 rows
select * from cwd_user_attributes where lower_attribute_value = 'false' and attribute_name != 'requiresPasswordChange';
and
There is 1 or more
attribute_name
returned from the query above is listed as something that would normally store a numeral. This includes the following:"login.lastLoginMillis"; "login.previousLoginMillis"; "login.lastFailedLoginMillis"; "login.count"; "login.currentFailedCount"; "login.totalFailedCount";
Cause
An unknown process or function of Jira stores a string, "false" in the lower_attribute_value
column of the table cwd_user_attributes
that is expected to be a number. When this row is read by the application, it cannot be interpreted and is not handled gracefully, thus, the requested operation fails.
Solution
Update the rows identified by the ID fields located in the Diagnosis query to be a valid integer:
UPDATE cwd_user_attributes SET lower_attribute_value = 1639454041, attribute_value = 1639454041 WHERE id IN (list,of,id,from,diagnosis,query)
In the case of the
attribute_name
ending with "millis", the aboveattribute_value
is appropriate. It is a valid unix epoch timestamp. In the case of others (eg, ones ending with "count") you may want to adjustattribute_value
to something more sensible, like 1- After running the query, check the affected functions of Jira to check if they are working again. If not, you may need to restart the application in order to flush any cached values