Panic: My users get on the same journey 4 times!

[mattes3]

Some users on my list entered 4 times into the same journey. And the same emails are being sent out to them over and over again. I suddenly get 100s of unsubscribes for that reason.

Here is a screenshot from the user details of one such user:

The entrance node that did this is of type 'schedule once'. How could this happen more than once? And how can I stop the redundant emails from going out?

[pushchris]

That should definitely not be happening, also strange that the times for all of those are so different and there is no pattern (multiple days between, etc).

Can you provide the following:

SELECT jus.created_at as step_created_at, jus.type AS user_step_type, jus.id, ended_at, ref, js.type AS step_type, js.data, js.next_scheduled_at FROM journey_user_step jus
LEFT JOIN journey_steps js ON js.id = jus.step_id 
WHERE user_id = 1 AND entrance_id IS NULL

Where the user ID is the internal ID of the user you mentioned above? Would love to see what is happening here. The biggest thing to look for is that next_scheduled_at is null in the journey step since that is what dictates that the scheduler run again.

[mattes3]

This is what the SELECT statement gave me:

+---------------------+----------------+-------+---------------------+--------------------------------------+-----------+-------------------------------------------------------------------------------+-------------------+
| step_created_at     | user_step_type | id    | ended_at            | ref                                  | step_type | data                                                                          | next_scheduled_at |
+---------------------+----------------+-------+---------------------+--------------------------------------+-----------+-------------------------------------------------------------------------------+-------------------+
| 2024-04-07 13:38:11 | completed      |  2917 | 2024-04-10 13:41:10 | NULL                                 | entrance  | {"trigger": "event", "event_name": "user_created"}                            | NULL              |
| 2024-04-18 00:00:00 | completed      |  8922 | NULL                | 55d3673d-b101-4ddf-a776-07d7df625770 | entrance  | {"list_id": 5, "trigger": "schedule", "schedule": "DTSTART:20240418T000000Z"} | NULL              |
| 2024-04-21 09:00:00 | completed      | 15460 | NULL                | 967b1026-8987-4925-94ed-153cf1bc9253 | entrance  | {"list_id": 5, "trigger": "schedule", "schedule": "DTSTART:20240418T000000Z"} | NULL              |
| 2024-04-21 10:00:00 | completed      | 17661 | NULL                | 8eddc382-4249-4fb5-b421-d53ad70e5870 | entrance  | {"list_id": 5, "trigger": "schedule", "schedule": "DTSTART:20240418T000000Z"} | NULL              |
| 2024-04-23 20:00:00 | completed      | 27749 | NULL                | 51045d96-63a2-4922-bd4e-d47aaf0b0829 | entrance  | {"list_id": 5, "trigger": "schedule", "schedule": "DTSTART:20240418T000000Z"} | NULL              |
+---------------------+----------------+-------+---------------------+--------------------------------------+-----------+-------------------------------------------------------------------------------+-------------------+
5 rows in set (0.01 sec)

[mattes3]

I edited the journey diagram a few times. Is it possible that every time I clicked 'Save' a new entry into the table has been created?

[mattes3]

I have seen that all those journeys are still running. The one from April 18, 00:00:00, is the correct one, it should continue to run. The others urgently need to be stopped. How can I stop the other 3 journeys for all users, before 20:00 UTC today?

[mattes3]

I realize that some users have different journeys with different dates. The next emails will go out at 5:00 UTC which is in less than half an hour.

So I will stop the API and the worker containers for now so that my users are not spammed. I will keep the database running so that I can send you more data if needed.

Here is another user who has the same problem but different times:

Database:

+---------------------+----------------+-------+---------------------+--------------------------------------+-----------+-------------------------------------------------------------------------------+-------------------+
| step_created_at     | user_step_type | id    | ended_at            | ref                                  | step_type | data                                                                          | next_scheduled_at |
+---------------------+----------------+-------+---------------------+--------------------------------------+-----------+-------------------------------------------------------------------------------+-------------------+
| 2024-04-07 13:37:40 | completed      |  2314 | 2024-04-10 13:40:13 | NULL                                 | entrance  | {"trigger": "event", "event_name": "user_created"}                            | NULL              |
| 2024-04-20 00:00:00 | completed      | 11047 | NULL                | 34139dd3-8654-42bc-9dfe-37a127ed92bf | entrance  | {"list_id": 4, "trigger": "schedule", "schedule": "DTSTART:20240420T000000Z"} | NULL              |
| 2024-04-21 09:00:00 | completed      | 15160 | NULL                | b1ef06cf-56c5-4655-b435-03ad32af9992 | entrance  | {"list_id": 4, "trigger": "schedule", "schedule": "DTSTART:20240420T000000Z"} | NULL              |
| 2024-04-23 17:00:00 | completed      | 26336 | NULL                | f9ea30b8-5ec2-4f5c-a8c5-90bcb1df8acf | entrance  | {"list_id": 4, "trigger": "schedule", "schedule": "DTSTART:20240420T000000Z"} | NULL              |
| 2024-04-23 20:00:00 | completed      | 28217 | NULL                | f37ad03d-45a5-407a-8601-0f9bbf99a7ec | entrance  | {"list_id": 4, "trigger": "schedule", "schedule": "DTSTART:20240420T000000Z"} | NULL              |
+---------------------+----------------+-------+---------------------+--------------------------------------+-----------+-------------------------------------------------------------------------------+-------------------+
5 rows in set (0.01 sec)

[pushchris]

You should be able to somewhat selectively delete users along the journey with something like the following:

DELETE FROM journey_user_step WHERE id IN (
    SELECT * FROM (
        SELECT id FROM journey_user_step WHERE entrance_id IN (
            SELECT id FROM journey_user_step WHERE entrance_id IS NULL AND created_at > '2024-04-18 00:00:00' AND step_id = STEP_ID_HERE
        )
    ) as p
)

DELETE FROM journey_user_step WHERE id IN (
    SELECT * FROM (
        SELECT id FROM journey_user_step WHERE entrance_id IS NULL AND created_at > '2024-04-18 00:00:00' AND step_id = STEP_ID_HERE
    ) as p
)

You'll just need to find the step_id which you can get by adding to the following:

SELECT jus.step_id,  jus.created_at as step_created_at, jus.type AS user_step_type, jus.id, ended_at, ref, js.type AS step_type, js.data, js.next_scheduled_at FROM journey_user_step jus
LEFT JOIN journey_steps js ON js.id = jus.step_id 
WHERE user_id = 1 AND entrance_id IS NULL

I also assumed that the correct entrance for folks happened before 2024-04-18 00:00:00

I would then just not run save for now until I can figure out what is going on. You can also completely turn the journey off by unpublishing it and it will stop all processing.

[mattes3]

Okay, I started the containers again and unpublished the two journeys.

[pushchris]

Ok, you were correct, it was related to you re-saving the journey. Previously when there wasn't a "once" style scheduled journey we assumed that we should recalculate when the next scheduled send would be every time you saved (since we re-save all journey steps on save) since it could've changed. In moving to a "once" style scheduling you don't want that to happen but rather only change the scheduled at date when the end user changes the date manually. The latest release (from #463) addresses this. It also prevents multiple entries in journeys regardless of saving the scheduling date.

However, this wont help or solve things for folks already in your journeys since this only affects entrances. You can run the above SQL to clear out the users who are in the journeys multiple times. Would also recommend removing the next_scheduled_at date for the entrance just to make sure it doesn't run again.

[mattes3]

I see. I've had a look at the SQL but I'm traveling right now. Will have time to do this tomorrow.

The SQL looks like there is a statement redundantly wrapped into another SELECT * from ... What does it do?

[pushchris]

MySQL has a weird issue with deleting items you've just selected so thats the workaround to make the query work. Here are some more details on the specifics of why it works: https://stackoverflow.com/questions/4562787/how-to-delete-from-select-in-mysql

[mattes3]

Okay, the delete statements seem to have their job. I can't help the folks who unsubscribed but at least, the sea is now calm again. Phew! 😥