View Issue Details

IDProjectCategoryView StatusLast Update
0017860phpList 3 applicationBounce Managementpublic20-07-17 08:52
Reporterdanwaterloo 
PrioritynormalSeverityfeatureReproducibilityalways
Status assignedResolutionopen 
Product Version3.2.1 
Target Versionnext patchFixed in Version 
Summary0017860: bounce processed multiple times unless deleted
Descriptionwhen processing bounces with a cron job and advanced bounce processing, an individual bounce is processed over and over again unless deleted.
Steps To ReproduceCron job, bounce processing, create a rule and set as "unconfirm subscriber"
Process the bounces several times, and see that the subscriber has been unsubscribed multiple times.

Additional InformationIt would be nice to process the bounce, and then keep the bounce message in the database, but do not re-process it on the next running of the cron job. Right now, it needs to be deleted to be 'not processed'.
TagsNo tags attached.

Activities

samtuke

15-05-17 15:40

administrator   ~0059069

I understand that this is by design. Are changes required?

michiel

23-05-17 22:28

manager   ~0059108


I've committed https://github.com/phpList/phplist3/commit/df85d80bf0abd0e6681a34e19cdd41cc4f62507a

to fix that.

Duncan, could you do a quick code review, to make sure I did it correctly?

Thanks

duncanc

24-05-17 18:06

developer   ~0059111

Last edited: 24-05-17 18:12

View 2 revisions

I think that the code change probably does what you intend but that isn't quite what was asked for.

Dan suggested not processing a bounce at all once it has had a bounce rule applied to it. The proposed code change will still process the bounce, try to match against bounce rules, but just not do any update that is inconsistent with the subscriber confirmed or blacklisted status. I think that last part is worth doing anyway but I think it is better if the bounce is just not processed by the advanced rules (or the consecutive bounce processing).

There is a possible problem with the code change. If a subscriber is say made unconfirmed by a rule, then the problem with his email address is resolved and he is made confirmed by an admin, then the next time bounces are processed he will be made unconfirmed again. I remember that the consecutive bounces processing had a similar problem but don't remember what the solution was.

Possibly the status column could be used to indicate that a bounce has been processed and should not be processed again. Currently the status column seems to hold additional comments such as these, instead of a status:

bounced list message 354
bounced unidentified message
bounced system message
unidentified bounce

duncanc

26-05-17 04:58

developer   ~0059120

The processing that finds the bounces to process can be simplified quite a bit.

We are interested only in rows of user_message_bounce that refer to a user who exists, so the main query that has an implicit join of bounce and user_message_bounce can have a further join to the user table to retrieve the columns of user that are used - id, email, confirmed, blacklisted.
That removes the need for a separate query for $userdata and the query in this change.

duncanc

20-07-17 08:52

developer   ~0059242

This is the consecutive bounces problem that I referred to in https://mantis.phplist.org/view.php?id=17860#c59111

https://mantis.phplist.org/view.php?id=16958