See #55 (comment)

These currently send our own defined format of run steps, whereas the new call_webhook action has a body template.

webhook.json.response.cities[0].name evaluates to just up to [0]. This is likely an issue with the parser

In the old world we populate the context with @channel.tel and @channel.tel_e164. In new world users have access to contact URN paths and so far @run.input.channel.address / @contact.channel.address which is E164 formatted.

So how should we let users get a friendlier version of telephone numbers? Could be an attribute like:

• @contact.urns.1.path.display
• @run.input.channel.address.display

or a function like:

• @(display(contact.urns.1.path))
• @(display(run.input.channel.address)

..or come up with a migration story for this crazy feature

Relevant RP test: temba.flows.FlowsTest.test_send_all_replies

These use single letter codes like A whereas elsewhere we use more descriptive constants like "datetime" or "msg_wait"

>, <, <=, >=, = and != should always cast arguments to decimal (and error if not possible to). Ambiguity with string is confusing and unpredictable.

Likely solution is something where we return a context of the flow at that place and it is up to container to deal with substituting contact vars

Need a way to request a language preference.

In RP, we look at Contact language, then Org primary language, then Flow default language. In the new world we are only looking at contact. While this seems like a reasonable simplification, we need to be able to bring current behavior forward.

A RP test when run through goflow that exposes this is: temba.flows.FlowsTest.test_cross_language_import

https://github.com/nyaruka/rapidpro/blob/1474af3e12b6e6a6b268b942541934bcede8f31e/temba/flows/tests.py#L5571

Repro:

• Create node waiting for inbound message to start a flow
• Start that flow with an inbound message

See: temba.flows.tests.TriggerStartTest.test_trigger_capture

The first node's wait should be satisfied by that inbound message

Use it anywhere we use timezones

Opening this to track and discuss our feelings on fuzzy matching in the new engine. RP tests like contains_any use levenshtein for edit distance. Unless we use the same going forward we will see inconsistent results. Don't believe we added have any sort of fuzzy matching so far.

In order to match path activity with legacy data, when we migrate a flow forward the exit uuid needs to be an existing rule_uuid. The old system tracks activity data by rule match, then adds up all like-named categories. Since we have discreet exits we need to use the first like-named category's uuid as the exit uuid during migration.

Should be stuffed in the session so it can be referred to in later steps

And propagate its values.. ??

Could convert regexes like we once did for Java, e.g. https://github.com/rapidpro/flows/blob/master/java/src/main/java/io/rapidpro/flows/definition/tests/text/RegexTest.java#L96

HasWard
HasDistrict
HasState

We probably don't want to send all adminboundary information with every request, so need a solution that either caches this, calls back to the caller, or accesses an external service.

We may want to give callers more granular control on how to reliably handle error events. For example, it may be useful to take a different action if the flow blew up due to a runtime cycle.

Flow definition: webhook-failure.json.zip

ERRO[1396] request complete http_method=POST http_proto="HTTP/1.1" http_scheme=http panic="runtime error: invalid memory address or nil pointer dereference" remote_addr="[::1]:52361" req_id="esquandolas.local/IAYbjAE4Qo-000007" resp_bytes_length=22 resp_elasped_ms=0.592514 resp_status=500

E.g. I keep seeing start_flow: field 'uui_d' required

Currently these actions in RapidPro take one of 3 things as a label or group:

• A dict with uuid and name fields
• A string representing the label/group name
• An expression (only evaluated if it begins with a @ char)

My first inclination is that we should drop support for expressions here because we shouldn't give users enough rope to create millions of groups/labels by accident.

Flow server should spawn a background thread which deletes stuff from the cache which hasn't accessed in a configured period of time

Need a way to deal with localized arguments. Currently, localization is a string pair, but arguments for cases are slices.

Also, various tests aren't looking up localized versions of their arguments.

RP has a unit test that:

• Starts the flow, stopping at a wait
• Modifies that wait into a passive split
• Sends a new message to resume through that ruleset having the message picked up by the next wait

Seen here: temba.flows.FlowsTest.test_rule_changes_under_us

Running this sort of test in the new world results in cannot resume flow at node [uuid] which no longer contains wait.

Need to determine how want to mitigate this behavior going forward.

• Ansible
• What URL is hit?

Currently in RapidPro each variable is resolved as follows:

1. If it equals @new_contact, create a new empty contact and send to that
2. Evaluate it as an expression
3. Try to match it as a contact UUID
4. Try to match it as a group name
5. Try to match it as a phone number

We could emulate that in goflow as:

1. If it equals @new_contact, send that back to rapidpro in the contacts list so it knows to create a contact
2. Evaluate it as an expression
3. If it looks like a UUID send that back in the contacts list
4. If it matches the name of a group asset, send that group back in the groups list
5. If it is a valid phone number send that back in the URNs list

But is now the time to clean this up and make it more explicit?

In old world, RegexTest has access to the run and adds the matches to @extra on the run. In the new world, tests are expressions which know nothing of runs.

Either:

• we introduce a mechanism for tests to return a dict that can be automatically added to @extra by the router
• we introduce an action for users to explicitly add things to extra, and allow them to add the result of an expression which returns the matching groups. We could then migrate rulesets with regex tests to nodes that include this action before the switch router
• we introduce an expression to the old world which allows users to regex parse input and see if we can change existing flows to using this in expression type rulesets instead of relying on @extra

I think I'm leaning toward the latter option because implicitly changing @extra isn't something I particularly want to support in the new world.

has_pattern("buy btc", "Buy (\w+)").match = ["buy btc", "btc"]
has_pattern("buy btc", "Buy (\w+)").match.0 == "buy btc"
has_pattern("buy btc", "Buy (\w+)").match.1 == "btc"

the flow result saved from a router case with this test would still be match.0. This doesn't provide an automatic solution to #69 but does provide equivalent functionality

With no waits.. should detect and shortcut

We do actions, events, routers, but not nodes etc..

IE, do something like @(TO_JSON(run.results)) and get something like:

{
   "foo_bar": {

   }, etc..

}

Webhooks can take a bit.. and sometimes it is nice to send status to the user that it may take a while, but since we return everything at once (the commands to send the status and the webhook result) that doesn't work.

Hrmm

We need a solution that:

• Avoids the caller needing to sending flow (etc) definitions with every request
• Supports location data being an asset type and thus solves #71
• Allows the caller to provide an up-to-date definition when necessary, e.g. the simulator needs to run with the absolute latest version of a flow

One option would be something similar to <script> and <style> elements in HTML where they can be embedded resources, or linked resources.

"assets": [
  {"type": "channel", "uuid": "7a3b...", "src": "http://rpd.io/as/flows/7a3b..."},
  {"type": "flow", "uuid": "4af6...", "src": "http://rpd.io/as/flows/4af6..."},
  {"type": "flow", "def": {
    "uuid": "a9c6...",
    "nodes": [...]
  }},
]

So in the simulator case, it would send flows as embedded definitions, but probably all real world use we would send just the links. Goflow would then be responsible for caching those definitions for X amount of time.

If we wanted to support longer caching we could give callers the ability to invalidate or update goflow's asset cache when they know something has changed, e.g. an /assets endpoint