WhatsApp error handling

[rudigiesler]

When sending a message, the WhatsApp API might return a 400 error. Some of these errors might be useful to be able to action on, eg.

1013, not a WhatsApp user
1006, unknown contact

These kinds of errors happen often with number churn.

It would be nice to be able to do some sort of action on receipt of these errors, eg. send the user the message over SMS instead, but I'm not sure what the best way to go about this in RapidPro is.

I think it would be useful to have a discussion if this is something that RapidPro would support, and if so, how we could go about implementing it.

[nicpottier]

So the closest we have to this is stopping a contact when we know they can no longer be reached. That's generally in response to a Twilio code when we try to send to them:
https://github.com/nyaruka/courier/blob/master/handlers/twiml/twiml.go#L264

That however causes the entire contact to be marked as stopped, not just that URN.

WhatsApp is an interesting case because from a WhatsApp URN you can derive a real telephone number, which is pretty unique among channels. Generally if someone is unreachable then they are unreachable, at the very least that URN specifically is.

So anyways, ya, not sure how this would be modeled.

I guess in an ideal future would I could imagine something like this:

• Channels can generate channel events when they send. We probably don't want these for any error at all, but for sure cases like Twilio stop events or WhatsApp not a user events we could. Maybe that's the same as the current stop channel event.
• In RapidPro you can set up a trigger based on that channel event.. ie: when a contact is stopped start this flow. ¹
• In that flow you can do some URN tom foolery to turn the WhatsApp URN into a tel URN and add that as a URN instead, perhaps additionally annotating the contact in some way.

That feels the most "flowy" way of addressing this long term. Basically move stopping / blocking to be flow actions (perhaps really unifying those two and letting the user annotate contacts if they want to differentiate them) and let you wire up triggers for some a broader set of channel events beyond the more typical Start Conversation triggers currently supported.

@ericnewcomer @rowanseymour @norkans7 thoughts?

Footnotes

1. this gets tricky, right now when a contact is stopped in RapidPro they are removed from all groups and can't participate in flows etc, we may have to rethink how this works or at least the language around these events. Perhaps there's a default flow that has a "Block Contact" action in it that accounts have by default that lets people control this behavior? ↩

[rowanseymour]

I do think we still need to preserve the distinction between blocked (user initiated) and stopped (contact initiated) because you can into trouble if you revert/ignore the latter.. and I'm not sure there's a strong argument to put that burden on the user via custom fields.. but maybe there's a better way to model this than is_stopped and is_blocked.

I definitely like the idea of users having control over the "stopping" and it fits with something we've talked about for a while now - "non-interactive flows" with their own rules about what is allowed.

Tho for this specific use case.. I do wonder how likely is it that a user would cease to be reachable on WhatsApp but still be reachable (and the same actual person) over SMS? I'm not even sure how a phone number ceases to be a WhatsApp user..

[rudigiesler]

We haven't done research in the specific reasons, but we do know that this happens quite a lot in practice. The reasons could be things like uninstalling WhatsApp, or switching to a non-smartphone that doesn't support WhatsApp, or they never had WhatsApp to begin with, but the previous owner of their phone number did, and the WhatsApp account only expired after they were given the number (I'm not sure how long WhatsApp keeps control of the accounts).

[rowanseymour]

I guess that's the key question - how long does WhatsApp remember the accounts. If I put my SIM card in a non-smartphone now, how long before anything changes on the WhatsApp side.

[rudigiesler]

I found this resource from WhatsApp, seems like 45 days is the answer: https://faq.whatsapp.com/en/general/24068052

[ericnewcomer]

Just want to weigh in here that I really like the event > trigger model. Not just for this case but in general. The more things that logically fit this paradigm the more multiplicative the power the platform gets. As long as we aren’t squinting too hard to fit it which in this case I don’t think we would be.