java.lang.NumberFormatException: For input string: "false" occurs when loading user list or logging in
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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:
1
2
3
4
5
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
1
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:1 2 3 4 5 6
"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:
1 2 3
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 1After 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
Was this helpful?