Open JuliusR opened 3 years ago
Hmm that's weird. Apparently @users
could not be loaded. It is set here.
Could it be that natural_search or pagination has issues?
I believe that @users
is properly set, but one of the users causes some inner code to fail. Since the error reporting is not perfect, it blaims that line. I asked the original reporter to perform some tests. You received a copy of my email.
Hi Julius, I checked the links you provided me via e-mail while being logged in. The set of links to the first 5 pages of the user list did work, while the last link returned an internal server error. I hope this helps, please come back to me if there is something else I should test. Kind regards David
For the record: these are the five pages that are working
/NAME_OF_FOODCOOP/admin/users?page=1&per_page=1
/NAME_OF_FOODCOOP/admin/users?page=2&per_page=1
/NAME_OF_FOODCOOP/admin/users?page=3&per_page=1
/NAME_OF_FOODCOOP/admin/users?page=4&per_page=1
/NAME_OF_FOODCOOP/admin/users?page=5&per_page=1
, and the failing page is
/NAME_OF_FOODCOOP/admin/users?page=1&per_page=0
@RelevanterUsername it is good that the first 5 pages are working. You should see 1 user per page. Let us find the exact user that causes the error in the admin view (not his personal fault, though). The first page fails for you if you are showing 20 users per page (the default). The first 5 users are fine, so could you please check the remaining 15 users? I will send you personalized links by email.
@wvengen: I could reproduce a problem on the rails console
.
The following code (taken from here) fails at page 14
(13..15).each{|i| puts User.undeleted.includes(:mail_delivery_status).natural_order.page(i).per(1).first.inspect }
, but the following code works fine
(13..15).each{|i| puts User.undeleted.natural_order.page(i).per(1).first.inspect }
Looking at that User I noticed a case mismatch of the mail address:
irb(main):078:0> User.undeleted.natural_order.page(14).per(1).first.email
=> # [email address with lowercase first letter]
irb(main):079:0> User.undeleted.natural_order.page(14).per(1).first.mail_delivery_status.first.email
=> # [email address with UPPERCASE first letter]
I believe that is the problem here. Users and mail delivery status are joined by email address.
Hi Julius, I checked the new links and one of them is not working. It is the middle one, which is linked to the user Helge (probably, of course I did not see it, because the link does not work, but the other two are correctly named). Regards David
I checked the new links and one of them is not working. It is the middle one,
OK, great. We found the problem then: case mismatch of email address.
As a temporary workaround, you @RelevanterUsername can perform user administration using the following entry points:
/NAME_OF_FOODCOOP/admin/users?page=1&per_page=13
/NAME_OF_FOODCOOP/admin/users?page=2&per_page=14
The first link shows all users before the problematic one, and the second link shows 14 users immediately after the problematic one. Starting from the second link, you should be able to use the links to follow-up pages. Should I send you personalized links by email?
The collation of primary-key and foreign-key columns may be relevant here.
MariaDB [(none)]> SELECT * FROM INFORMATION_SCHEMA.SCHEMATA WHERE schema_name = 'NAME_OF_FOODCOOP';
+--------------+----------------+----------------------------+------------------------+----------+
| CATALOG_NAME | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH |
+--------------+----------------+----------------------------+------------------------+----------+
| def | NAME_OF_FOODCOOP | utf8mb4 | utf8mb4_unicode_520_ci | NULL |
+--------------+----------------+----------------------------+------------------------+----------+
1 row in set (0.001 sec)
MariaDB [(none)]> SELECT column_name, character_set_name, collation_name from information_schema.columns WHERE table_schema='NAME_OF_FOODCOOP' AND table_name = 'users';
+------------------------+--------------------+-----------------+
| column_name | character_set_name | collation_name |
+------------------------+--------------------+-----------------+
| id | NULL | NULL |
| nick | utf8 | utf8_general_ci |
| password_hash | utf8 | utf8_general_ci |
| password_salt | utf8 | utf8_general_ci |
| first_name | utf8 | utf8_general_ci |
| last_name | utf8 | utf8_general_ci |
| email | utf8 | utf8_general_ci |
| phone | utf8 | utf8_general_ci |
| created_on | NULL | NULL |
| reset_password_token | utf8 | utf8_general_ci |
| reset_password_expires | NULL | NULL |
| last_login | NULL | NULL |
| last_activity | NULL | NULL |
| deleted_at | NULL | NULL |
| iban | utf8 | utf8_general_ci |
+------------------------+--------------------+-----------------+
15 rows in set (0.003 sec)
MariaDB [(none)]> SELECT column_name, character_set_name, collation_name from information_schema.columns WHERE table_schema='NAME_OF_FOODCOOP' AND table_name = 'mail_delivery_status';
+-----------------+--------------------+-----------------+
| column_name | character_set_name | collation_name |
+-----------------+--------------------+-----------------+
| id | NULL | NULL |
| created_at | NULL | NULL |
| email | utf8 | utf8_unicode_ci |
| message | utf8 | utf8_unicode_ci |
| attachment_mime | utf8 | utf8_unicode_ci |
| attachment_data | NULL | NULL |
+-----------------+--------------------+-----------------+
6 rows in set (0.040 sec)
The relevant part for this bug is the _ci
suffix. Let us discuss the utf8
vs utf8mb4
issue somewhere else.
Wow, good debugging, thanks!
I have not been able to reproduce it on my own yet. Here is an excerpt from a production system. It appeared around
2021-01-02T11:29:30.346621
.