Closed ejaxon closed 2 years ago
Maybe the call to subscribe creates a DB record and immediately returns a unique identifier for that subscription to the frontend, which then polls the API every second or three for the status of that subscription? If the answer is "pending" or similar, show a spinner or just "Processing…" If the answer is "subscribed" or "success" or whatever, then show the confirmation message and stop polling. If the answer is "failed," show the failure message and stop polling.
I guess this introduces the additional maintenance task of clearing out failed subscriptions. 🤷🏼♂️
That makes sense. The poll itself can trigger the cleanup - for the first few seconds the endpoint will just return "Pending," but if there's no success after, say, 5 seconds, it undoes the subscription and returns "Failed". We can add a column to subscriptions for "confirmed" and add a cleanup to the daily purge for the edge cases that don't get purged by the poll.
As Jay suggested, the front-end now polls until it gets confirmation of success, otherwise it marks it as failed (3 tries, 500 ms apart). On the back end there is a new webhook that gets delivery status for all messages. If the subscription is pending it marks it failed immediately. If a failure occurs after initially successfully confirming the subscription, it increments a failure counter. When it hits the 3rd failure, it marks it failed. The purge routine purges all subscribers marked failed (and associated defendants and cases).
Sorry - make that 6 tries, 500 ms apart.
The current registerSubscription code assumes that a failed send will generate an exception, but that only happens in the case that the phone number itself is determined to be invalid. Otherwise Twilio just queues the message to send and returns, so we have no idea, for example, if the phone is a landline that can't accept messages.
We need to send with a status callback URL and not send the confirmation to the user until that is received.
This will be tricky to do. We'll need to have the callback endpoint record it in the DB and have a way for the subscription to check that after a second or two before responding to the user.