In order to replicate our replag issues we need a reliable way to trigger it.

We have been using

drush cvapi Omnigroupmember.load group_id=310   mail_provider=Silverpop group_identifier=18468760

However, this is becoming more unreliable as we go as

1. when we restart the process it restarts from the beginning of the csv,meaning that the next time we test we get a unspecified delay before it hits the ones it needs to insert
2. there seem to be a number of remind-me-later contacts that are already in our DB, but they have no contact_id in silverpop because they are opted out, on_hold or otherwise blocked from being send to silverpop

over time these seem to be hogging more of the start of the file - leading to #1 above

My current thinking is to change the job so that with specfic parameters it can be changed to import to a table first & then from there into the DB. The advantage of this is we can skip the DB part if we choose.

This does add another variable - the cache tables. I would not expect the transit table to affect the caches. However, I am unsure whether hitting the issue without caches affect would rule cache involvement in or out, given that we did hit this with the other silverpop data & the sheer volume seemed likely to be an issue there.