Skip to main content

First End-to-End Flow

The recommended first flow in this repo is the flow_lab parse path. It is small, local-only, and exercises the Triggers v2 loop without extra product setup.

Start with this shape:

source (flow_lab_in)
  -> service (flow_lab)
      -> action (parse)

Do not start with a chained graph. First prove one service registration and one successful run. Then extend it.

1. Bring up the runtime​

From notify_triggers/:

cd /Users/claudiu/dev/newton/momentum-online/notify_triggers
make local-infra
make local-up

2. Register the source and run the service​

From triggers-sdk-go/examples/flow_lab/:

cd /Users/claudiu/dev/newton/momentum-online/triggers-sdk-go/examples/flow_lab
make seed
make run

Keep make run active in its own terminal.

3. Inspect registration before touching Studio​

In another shell:

curl -s http://localhost:8888/api/v2/services/flow_lab | jq .

This is your first inspection point. Before you create a flow, confirm that:

  • the service exists at /api/v2/services/flow_lab
  • liveness is online
  • the manifest exposes parse and wrap

If registration is missing, the rest of the flow will not work.

4. Create the first allowed graph​

In Studio, create a flow that uses source flow_lab_in, then add the flow_lab service and its parse action.

Keep the graph grammar from the example README:

  • source never connects directly to action
  • action never connects directly to action

That is the right first flow for this walkthrough. The broader graph can also place nodes such as condition, rate-limit, mapping, output-topic, or service-in between the source and the first service action.

That means this is valid for a first flow:

source -> service(flow_lab) -> action(parse)

and this is not the right first move:

source -> action(parse)

Map the incoming message field into parse.message, then release the flow. If your Studio workflow keeps release and enable separate, enable it too.

5. Produce one event​

Back in the flow_lab example folder:

make produce

This is your source event for the first run.

6. Inspect runs​

Use the flow ID from Studio:

curl -s "http://localhost:8888/api/v2/flows/<flow_id>/runs" | jq .

This is your second inspection point. It tells you whether the released flow actually ran after the source event arrived.

7. What to do after the first success​

Once the parse path works, the next useful extension is the chained example from flow_lab:

source (flow_lab_in)
  -> service (flow_lab)
      -> action (parse)
  -> service (flow_lab)
      -> action (wrap)

Why the extra service segment? Because in the repo's graph grammar, an action does not connect directly to another action. Chaining depends on the upstream action declaring result_event, then binding wrap inputs from the parse result fields.

That is the point where result_event stops being abstract and starts mattering in daily work.