Closed (fixed)
Project:
Persistent Login
Version:
2.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
2 Oct 2024 at 19:02 UTC
Updated:
18 Oct 2024 at 22:59 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
jan kellermann commentedWe did this:
Comment #4
fenstratAlso hit this, only where uid1 had a persistent login.
The approach from #2 is correct, this should only delete if there's something to delete. I have pushed those changes to an MR.
Comment #8
gappleThanks for the quick patch & review :)
New patch releases should be available shortly.
Comment #9
cslevy commentedThis still doesn't fix the issue. I attached an extra patch, which also should be included.
Comment #10
andrerb commentedThanks for the patch. I also still had the problem. After the 3rd iteration of the update hook and the query for $token_users, $sandbox[‘current’] was set to the last item in the pl table. Therefore the $token_users array was empty and the following query for $valid_users failed. Patch from #9 fixed the problem.
Comment #11
maxpahHello !
Thanks for the quick patch and release but this still crash on my side.
Additionnal patch #9 is working.
Comment #12
gappleThat's odd... On the last iteration
$sandbox['#finished'] = $sandbox['processed'] / $sandbox['total'];should equal1to complete the batch.Are there tokens stored for the anonymous user (uid:0)? That would increase
$sandbox['total']to one more than will be returned in the$token_usersqueries - but that shouldn't happen so some checks might need to be added elsewhere 😬.Comment #15
gapple🤞 that's a final fix for this issue.
Just wanted to also note that the tokens in the database aren't accepted even if provided by a browser, and this cleanup is only really needed for sites with tokens configured to a permanent lifetime, so there isn't a problem if the update is not completed on a site (provided it doesn't block any other necessary updates).