DoSomethingArchive / gambit-content

:black_joker: Content API for Gambit
MIT License
2 stars 5 forks source link

Unable to restart a reportback flow after a failed submission #506

Closed jonuy closed 7 years ago

jonuy commented 8 years ago

Update:

TODO - last updated Aug 2, 2016

This was found while a campaign is in an unpublished test state. Unsure of how much this affects us in an actual launch on production, but it sounds like it could affect us if errors do crop up.

Steps

  1. Submit reportback to an unpublished campaign
  2. Submission should fail because unpublished campaigns don't accept SMS reportback submissions
  3. Start reportback flow again
  4. On the step where it asks for you to submit a picture, just reply with a text-only message
  5. User doesn't get a response

This seen while testing on this account: https://secure.mcommons.com/profiles/166515827

tongxiang commented 8 years ago

Issue surfaced again while @ArielSD was testing GGW. The following document was created, but wasn't submitted or deleted and thus blocked other text-only submissions at the submit picture phase of reportbacks:

{
  __v: 0,
  _id: ObjectId("5630ec623f43e00e007010a3"),
  campaign: "ggw2015",
  caption: "Test",
  phone: "{ariel's phone number was here}",
  photo: "https://s3.amazonaws.com/mms.mcommons.com/mms/1397726/9WmcchWIUyQOqcMz",
  quantity: "1",
  started_at: ISODate("2015-10-28T15:40:18.839Z"),
  why_important: "Test"
}
aaronschachter commented 8 years ago

SMS RB: Reportback messaging not being sent to user(s)

aaronschachter commented 8 years ago

i've found a few scenarios where the member can reach The Dead Zone™

  1. Member texts in the REPORTBACK keyword and completes the flow, but the Phoenix API is down, so we never create an actual Reportback. I haven't gotten into what the Q library is doing here yet, but my guess is it's not retrying to submit the failed reportback.
    Member texts in REPORTBACK again to retry. The reportback.handleUserResponse function is called -- but won't execute anything because we already have all of the required properties stored on the Reportback in our Mongo reportback document for the user/campaign. handleUserResponse currently only submits the Reportback to Phoenix after collecting the why_participated value, which in this 2nd round we never do because we already have a value. Thus the member has now entered The Dead Zone™
  2. Our invalid Quantity opt-in-paths don't seem to point to an mData (example). So entering text for the quantity question would unlock The Dead Zone™. I'm wondering if we mistakenly stopped adding these mData's for invalid data OIP's between the time this issue was filed and #463, which suggests you complete flow but data is incorrect.
  3. There's a real pickle you can get into by leaving the Reportback flow at just the right time:
    • Begin reportback flow by texting REPORTBACK: submit picture, and caption.
    • When asked for quantity, text REPORTBACK again to begin the flow. you'll be asked if you can send pics from your phone, and then for a picture.
    • Based on your state, Gambit is not expecting a picture, but instead a different property: slack for ios upload-2

One simple solution here may be to wipe the document anytime the member starts the REPORTBACK keyword. That's not exactly the nicest. Thinking through a way improve the logic, but wanted to update on ways this can happen.

cc @justkika @jamjensen @classicfreddie

aaronschachter commented 8 years ago

Updated issue description with checklist for various scenarios (with links to corresponding issues when available).

aaronschachter commented 7 years ago

New chatbot endpoint should have resolved this.