NOTE:: Before reporting an issue, make sure you are running the latest version, currently 3.3.1

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0018524phplist applicationAll Otherpublic08-02-17 10:3912-02-17 12:34
PrioritynormalSeverityblockReproducibilityhave not tried
PlatformOSOS Version
Product Version3.3.1-RC1 
Target Version3.3.1Fixed in Version3.3.1 
Summary0018524: Comments on 3.3.1-RC1
DescriptionIn file actions/processqueue there is an error in the assignment of uuids for messages. The code actually updates the user table instead.

When there are more than 400 subscribers then the upgrade process delays assigning uuids for subscribers until the next run of process queue. I think it would be helpful to display a message explaining that.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
alexei (reporter)
09-02-17 14:37

On this line [^]
It asks for where uuid is not set, but on this line [^]
It's actually changing uniqid, which on the next run it goes through all of the subscribers (we have like 35K) again
The same story with these lines: [^] [^]
Processing all of our subscribers takes ~30min every time the query submit runs, this is why query processing looks like it get stuck.
alexei (reporter)
09-02-17 14:40

So the solution is to change uniqid to uuid in the DB update calls.
This is also messed up uniqid in our DB since it was regenerating it all the time.
So I would say this is not a minor bug
duncanc (developer)
09-02-17 14:51

You appear to be looking at an old version of the code. If you download 3.3.1-RC1 then some of this will have been fixed. But there is still a problem with assigning UUIDs to messages, which might have an effect by changing the UUID of some subscribers.
alexei (reporter)
09-02-17 15:30

The bug is in [^] Which is supposed to be stable.
alexei (reporter)
09-02-17 15:33

So it needs to be fixed with new stable release ASAP. Thanks for looking into it.
samtuke (administrator)
09-02-17 15:40

> The bug is in [^] [^] Which is supposed to be stable.

See here for the latest version: [^]
alexei (reporter)
09-02-17 16:19

Would you mind posting here: [^] that version 3.3.0 was recalled and one should revert back to 3.2.7 as described here [^] So that everybody who downloaded 3.3.0 are aware of the situation.
samtuke (administrator)
10-02-17 19:24

From the forum ( [^]):

> Some progress. New campaign will process queue to an extent. I have set the batch size to 120 and the time to 60 seconds. phpList 3.3.1-RC1 will process 120 addresses then freeze after about 40 seconds. Resume processing button does not work unless I wait several minutes. Upper frame in Send Queue window does have progress text but not lower window...
samtuke (administrator)
10-02-17 19:33

@alexei Thanks for the suggestion. That list is reserved for new release announcements and is distributed widely, so it's not a good place for such a statement.
michiel (manager)
10-02-17 21:11

This issue seems to have diverted but the original issue was fixed here [^]

However, that does not address "I think it would be helpful to display a message explaining that."

I will add something for that, as I agree.
duncanc (developer)
10-02-17 22:17

Michiel, you are still missing it. In actions/processqueue.php line 98 is updating the wrong table.
michiel (manager)
10-02-17 22:32

ah, yes, now I see it, thanks

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker