Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Campaign ends prematurely #2419

Closed
ToonGeneral opened this issue Aug 29, 2016 · 8 comments
Closed

Campaign ends prematurely #2419

ToonGeneral opened this issue Aug 29, 2016 · 8 comments
Assignees
Labels
bug Issues or PR's relating to bugs

Comments

@ToonGeneral
Copy link

What type of report is this:

Q A
Bug report? Y
Feature request?
Enhancement?

Description:

I originally raised a forum post about this but it only got one reply:
https://www.mautic.org/community/index.php/2965-campaign-events-disappear/p1#p8994

The fact at least one other person has experienced it suggests it's not entirely isolated to us. However, the fact that no one else is experiencing this issue with the regularity that we are, suggests there is something different that means we're triggering it more often.

We continued to experience this with new campaigns, to the extent that a high proportion of leads would trigger the first action (email 1) and then all other campaign events would be removed. As a result we stopped using lists/segments as the basis for campaigns, as we found a work around.

Rather than rely on segment membership, we now use a single segment that is always empty as the basis for all campaigns. We use a separate 'helper' campaign to trigger a 'Move campaign' action to force campaign membership. Everything works fine after that.

I have just updated to 2.1.1 and am beginning to set up a new process based on Stages. We're quite excited about the improvements Stages could have on our workflows. I have:

  1. built segments based on some stages
  2. built campaigns based on those segments
  3. put three contacts through this campaign
  4. all three:
  • get email 1 (triggers immediately)
  • get a stage change (triggers immediately)
  • the remaining 2x email events disappear

Let me know what other info to provide.

If a bug:

Q A
Mautic version 2.1.1
PHP version 5.6.25

Steps to reproduce:

  1. Build a segment based on any criteria
  2. Build a campaign based on segment membership
  3. Add contact to segment
  4. First campaign events trigger OK
  5. Contact is removed from campaign
  6. Subsequent events are removed as a result

Log errors:

Please check for related errors in the latest log file in [mautic root]/app/log/ and/or the web server's logs and post them here. Be sure to remove sensitive information if applicable.

@PatchRanger
Copy link
Contributor

It looks similar to #150.

@ToonGeneral
Copy link
Author

Thanks, I think you might be right. I'll stagger the crons as per #2004 and see what happens.

@ToonGeneral
Copy link
Author

Initial tests looks like this is what it was, plus conceptually it all makes sense. Closing, will reopen if it recurs.

@ToonGeneral
Copy link
Author

Unfortunately we are still seeing a problem.

I have staggered the three cron jobs to run as per the docs, every 15mins, staggered by 5 mins:
0-59/15 * * * * php /path-to-mautic/app/console mautic:segments:update --env=prod -f > /dev/null 2>&1 5-59/15 * * * * php /path-to-mautic/app/console mautic:campaigns:rebuild --env=prod -f > /dev/null 2>&1 10-59/15 * * * * php /path-to-mautic/app/console mautic:campaigns:trigger --env=prod -f > /dev/null 2>&1

We are still seeing the same problem; contact with first campaign event triggered 16:40 on 2nd Sept. Next event should trigger 16:40 5th Sept (today), instead, no longer on campaign.

My colleague who originally set this up back on a much earlier version of Mautic questioned the need to still have the -f flag. I've also realised that --env=prod is definitely no longer needed.

I've removed both and cron jobs are still executing correctly. I've also started collecting the output of the commands, but it's not very verbose. Will check contacts scheduled to execute tomorrow morning.

@ToonGeneral
Copy link
Author

OK, I don't believe this is a cron issue, but perhaps @alanhartless could weigh in, based on his post in #2004.

A contact had their next action (send email) due to trigger at 12:40. At 12:30 segments:update was triggered by cron. This is the output:
Rebuilding leads for list 80
2 total lead(s) to be added in batches of 300
0/2 [>---------------------------] 0%
1/2 [==============>-------------] 50%
2/2 [============================] 100%
6 total lead(s) to be removed in batches of 300
0/6 [>---------------------------] 0%
3/6 [==============>-------------] 50%
4/6 [==================>---------] 66%
5/6 [=======================>----] 83%
6/6 [============================] 100%

Membership of this segment is determined by:
Stage = x
Custom field 1 is not empty

Nothing has changed for this contact. There is no reason I can see for it to have been removed from this segment. This is validated by segments:update at 12:45 which decides to re-add the same contacts!
Rebuilding leads for list 80
6 total lead(s) to be added in batches of 300
0/6 [>---------------------------] 0%
1/6 [====>-----------------------] 16%
2/6 [=========>------------------] 33%
3/6 [==============>-------------] 50%
4/6 [==================>---------] 66%
5/6 [=======================>----] 83%
6/6 [============================] 100%
0 total lead(s) to be removed in batches of 300
6 lead(s) affected

To confirm, I am positive this completes within 1 minute (I think it's actually taking about a second). The next cron job runs 5 minutes later.

Also, to confirm, the symptoms look identical to when I posted in the forum back in March. We were not using Stages back then, segments would have been based on tags and the occasional custom field. Unfortunately I don't have log data from those issues.

Can I get some input because this looks fairly serious (and will continue affecting contacts on this campaign!).

@PatchRanger
Copy link
Contributor

@ToonGeneral Though my input might not be the one you are requested for - but let me chime in))

Supposed reason

As I mentioned in #150 (comment) , I believe that the reason of the issue is in the fact the campaign has wrong rebuilding mechanism:

  • It removes contacts from itself. I doubt that it removes all of the contacts, I believe that some still remain in campaign. But the important point is that it removes those which deserve to stay in.
  • All scheduled events for those contacts got deleted.
  • Campaign adds contacts back - but it doesn't (obviously) recover deleted events.

Supposed workaround

As I mentioned in #150 (comment) , I've workarounded the issue by commenting the line, which is responsible for removing scheduled events. It's not a solution, it's just a workaround to make sure that the supposed reason is correct. It works for me: I have not encountered any removings of scheduled events since then.

Hope it helps.

@ToonGeneral
Copy link
Author

Thanks @PatchRanger, your input is still appreciated :-)

Put simply, your fix def won't work for us, because I need our staff to be able to change a contacts stage and have them leave a campaign prematurely.

I have resurrected our previous work around, in that I modified the helper campaign to force a move to the main campaign, instead of just changing the stage and letting the segment change pick them up. This sets the 'manually added' field in campaign_leads and prevents the problem. It's messy, but we already have to have a helper campaign because I can't change the stage with an API call just yet, so it's not creating much extra for now. It doesn't scale well though and will go as soon as I can get this fixed and API control of stages is added!

I appreciate the efforts everyone contributing to the project is making, it's really progressed in the last few months, but this feels like something that really should get looked at.

@alanhartless
Copy link
Contributor

Please test this against #2716. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues or PR's relating to bugs
Projects
None yet
Development

No branches or pull requests

4 participants