Page MenuHomePhabricator

Silverpop import not importing entire database?
Closed, ResolvedPublic2 Estimated Story Points

Description

The nightly Silverpop imports generate a report in the ESP which tells me, among other things, how many rows were updated. This number has consistently matched the number of rows in the database - so I would expect somewhere around 7.8 million right now.

I checked those reports this morning after @awight confirmed he had made a change to the file (per T107045) and saw that only 2 million records were updated last night. The night before was ~5.5 million, which is around what it's been for the past couple of weeks. I don't have access to reports older than 11/5, so I'm not sure how long the import has been importing this number of rows.

We (Trilogy and me) are really concerned there is something wrong here, and are wondering if we need to stop sending email. Why were only 2 million records updated last night? Has the size of our database changed?

Can we look at the import file history and see when the row count changed from ~7.8m to ~5.5m?

UPDATE
I'm updated with what I believe is related information. Our email copy currently uses a personalization string which reads:
"you gave %%latest_native_amount%% to keep Wikipedia online..."

This has been working great for us, with no complaints to Donor Services once we got the code right. Today, DS received complaints from donors saying, "I gave X amount last year, why are you saying I only gave Y?" I investigated and the donors are correct - our Silverpop data does not match their Civi record. Examples below:

  • CID rMEXT8328610bd3eb: Donor last gave $5, Silverpop says $3 (donor never gave $3)
  • CID 8568645: Donor last gave $50, Silverpop says $5 (never gave $5)
  • CID 5641016: Donor last gave $75, Silverpop says $3 (never gave $3)

For what it's worth, the CIDs all match the donor emails, and Silverpop does seem to have the most recent CID for all these donors despite each having unmerged records. But the donation amounts are incorrect.

We are putting a hold on sending email until this is fixed. Confirming the previous donation amount was a 20% gain for us; we can't afford to remove it from the email, so we have to stop sending.

Event Timeline

CCogdill_WMF raised the priority of this task from to Unbreak Now!.
CCogdill_WMF updated the task description. (Show Details)

No doubt this is fallout from T107045, the export script is long and fragile. Agreed that the emails need to be stopped until we can fix the export.

I figured as much, @awight. It's fine by me to revert whatever changes were made in T107045 if that works as a stopgap for now.

@CCogdill_WMF
Thanks for the note. I'll revert that right away.

Change 254321 had a related patch set uploaded (by Awight):
Revert "Simplify latest donation calculation"

https://gerrit.wikimedia.org/r/254321

Thanks! I think sending email is more important than resolving the dedupe
issue - we've sent plenty with that unresolved. @MBeat33 let me know if it
seems like I'm minimizing the importance of T107045.

Le vendredi 20 novembre 2015, awight <no-reply@phabricator.wikimedia.org
<javascript:_e(%7B%7D,'cvml','no-reply@phabricator.wikimedia.org');>> a
écrit :

awight added a comment.

@CCogdill_WMF
Thanks for the note. I'll revert that right away.

TASK DETAIL

https://phabricator.wikimedia.org/T119105

EMAIL PREFERENCES

https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: awight
Cc: MBeat33, MeganHernandez_WMF, awight, CCogdill_WMF, Aklapper, DStrine,
cwdent, atgo

Change 254321 merged by jenkins-bot:
Revert "Simplify latest donation calculation"

https://gerrit.wikimedia.org/r/254321

Change 254323 had a related patch set uploaded (by Awight):
Revert "Simplify latest donation calculation"

https://gerrit.wikimedia.org/r/254323

Change 254323 merged by jenkins-bot:
Revert "Simplify latest donation calculation"

https://gerrit.wikimedia.org/r/254323

@CCogdill_WMF
The old code is redeployed and I've started an export job. It should be complete and uploaded in approx 2.5 hours.

Note that T107045 will be broken again, obviously.

Great, thank you @awight. I'm relieved to have email back, and so quickly!
I'll check the import report in silverpop tomorrow and make sure all rows
were imported as expected, as well as double check the three CIDs listed in
the description show accurate data.

Le vendredi 20 novembre 2015, awight <no-reply@phabricator.wikimedia.org> a
écrit :

awight added a comment.

@CCogdill_WMF
The old code is redeployed and I've started an export job. It should be
complete and uploaded in approx 2.5 hours.

Note that https://phabricator.wikimedia.org/T107045 will be broken again,
obviously.

TASK DETAIL

https://phabricator.wikimedia.org/T119105

EMAIL PREFERENCES

https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: awight
Cc: gerritbot, MBeat33, MeganHernandez_WMF, awight, CCogdill_WMF,
Aklapper, DStrine, cwdent, atgo

@awight looks like this didn't work. The file is back to importing ~5.4m rows (still about ~2.5m less than I'd expect), but it did not correct the incorrect data I highlighted for the CIDs in the task description. They still show a latest_native_amount which does not correspond with Civi.

We're going to keep email on hold for now, but hoping to send another ~500k on Monday and Tuesday if possbile. Keep me updated, please!

Sorry @CCogdill_WMF, we really should have been testing the data more than a few spot checks. At this point, @awight's last change (that cut the # of rows down so far) is rolled back, but my earlier change (tried to fix a few bad latest_donation dates, ended up introducing more errors) is still there.

I'm looking for a complete fix, but in case I don't find one I'll also get ready to undo my bad change and get us back to the situation of a couple weeks back when there were many fewer incorrect latest donations.

Thanks, @Ejegg, and no worries about spot checking. This is new territory
for all of us.

Is there a chance we can choose to pull the trigger on fixing/reverting by
Sunday? I would like emails to go out on Monday one way or another.

Per @Ejegg's email, I checked the Silverpop import report from 11/22 and we're back to importing ~7.5m rows! I double checked the 3 CIDs above and their records look correct in the database.

I'm adding a comment to T107045 with more info on the dedupe, which really does seem to be improved by this change as well. Thank you again! I'll close this task, but @MBeat33 please keep me posted if you see any other complaints — even one — about the accuracy of these personalization strings in the emails.

awight edited a custom field.