This folds into loop detection in goflow. We don't want to write a bunch of messages for a flow if we detect that that sprint was a loop.

Contact runs through a flow, starts a subflow which starts with a wait. That wait has a timeout.

One example to look at on TextIt:
https://textit.in/flowsession/json/1538002/

This run should time out at the first step after 30m.

Support for Twilio and Nexmo at launch.

Week of Jan 7th:

• twilio support for outgoing calls (through interface)
• channel log creation for all flow interactions
• download recordings to s3
• flow starts queue calls, calls start flows on callback
• channel logs for call status

Week of Jan 14th:

• validate signature on incoming requests
• create channel logs for call queuing
• handle incoming calls when trigger exists
• add nexmo support
• deal with nutty nexmo record callbacks
• add connections to flow start
• retry support on errored calls

Week of Jan 21st:

• create channel events for missed / incoming calls
• support for throttling number of active calls on channel
• end calls that have been ongoing for too long
• honor ivr_retry in flow metadata
• moar tests

In response to msg_created and msg_received events

Relevant legacy code:

• incoming https://github.com/nyaruka/rapidpro/blob/ce1e3d43966d56a91415bffd53f0e9cb4c7ed30e/temba/flows/models.py#L3002
• outgoing https://github.com/nyaruka/rapidpro/blob/ce1e3d43966d56a91415bffd53f0e9cb4c7ed30e/temba/flows/models.py#L5902

Default RP database is postgres://temba:temba@localhost/temba, mailroom unit tests currently run in postgres://temba@localhost/temba

Probably fine for them to both share test_temba

Surveyor sending the same payload twice throws https://sentry.io/nyaruka/rapidpro-mailroom/issues/868496661/

Goflow will return these once nyaruka/goflow#425 is merged.

To keep from clobbering state.

We use a redis cache already in RapidPro, do we use this or try for something better?

https://www.postgresql.org/docs/9.6/static/transaction-iso.html

Allow surveyor results to be posted to mailroom endpoint

• set up test harness, submit basic fully valid submissions
• deal with modifiers on groups / fields that no longer exit
• deal with modifiers that have no associated events (ie, removal from group that exists in db but wasn't in surveyor)

Config / environment needs to be loaded from db and cached.

Bit messy now (see TODO)

We want to queue in a batch for each contact (which we are) but need to handle case of having batch on differing channels

Need to add a method to switch flow_server_enabled to True on orgs. In that method we should do any required works such as switching all flows to flow_server_enabled to true. We should also set new IVR endpoints for Twilio and Nexmo when appropriate.

RapidPro v4.6.0 adds these fields and subsequent versions will backfill them and then make created_on non-null

I haven't been super consistent on the naming of all the utilities in models, need to do through and audit and rename them.

Current thinking is for extreme clarity, so things like, CreateContact should be InsertContact and things like GetContact should be SelectContact.. IE if we know for sure we are going to hit the DB, then we use Select .. if there may be a cache in between then we can use Get. Same rules for Update etc..

• per event/msg handled
• per flow started
• with handling latency

We use these for nullable fields but they are a pain in the ass in practice.

I'd much rather we build our own marshalled type we can inherit from that treats 0 as NULL in the db and null in json and does the same thing for strings. We could then use our Nil.. constants everywhere and remove a whole class of null pointer errors.

Just need to ensure nyaruka/rapidpro#2286 is pushed first

Tho only after nyaruka/rapidpro#2136 is deployed

The error message from goflow becomes the culprit field and is truncated to 200 chars. The message field is always set to client error but maybe this could be the full error message. E.g. https://sentry.io/nyaruka/rapidpro-mailroom/issues/861558893/

(because one of the names is empty?)

We should cache orgs and their assets, maybe 15 seconds at a time to start, then put in something smarter?

I.e. a replacement for https://github.com/nyaruka/goflow/tree/master/cmd/flowserver

Not the biggest of deals but all that polling will start adding up.

In a more sane way. (see TODO)

So that a log.WithField("foo", "bar").WithError(err).Error("error doing someithing") actually displays foo and bar in metadata.