Skip to main content

Sources

In Triggers v2, "source" can mean two related but distinct things. Keeping them separate will save you a lot of confusion.

Top-level flow sources​

A top-level source is the thing that starts a flow run when an event arrives. In the local onboarding path, flow_lab_in is that source. It is registered separately from any service and is what Studio uses as the graph entrypoint.

When you run:

make seed

in the flow_lab example, you are registering that flow-starting source.

Service ingress via service_sources​

A service also advertises ingress points inside its manifest using service_sources. These describe what a service segment can receive once a released flow routes into it.

Example:

  • flow_lab_in starts the flow
  • nats on the flow_lab service is the ingress declaration for service traffic

Those are not duplicates. They serve different steps in the runtime loop.

Common transport shapes​

The repo examples show three practical transport types:

  • Kafka for some flow-starting sources
  • NATS for service ingress and flow dispatch
  • HTTP for services that should expose an inbound HTTP surface

The richer notify-sender service advertises all three as service ingress options:

  • nats
  • kafka
  • http

That is useful when the same business action should be reachable from different transport contexts without changing the runtime model.

Studio-facing implication​

Studio cares about both levels:

  • top-level sources define where a flow starts
  • service ingress metadata helps describe how a service segment can be targeted

When you debug a broken flow, verify both ends. A valid released graph still will not run if the expected source was never registered or the expected service ingress is missing from the live manifest.

Local-first debug loop​

For source problems, use this sequence:

  1. Confirm the flow-starting source exists and matches the flow you released.
  2. Confirm the service is online.
  3. Inspect the service manifest and check its service_sources.
  4. Produce one event.
  5. Inspect runs and then DLQ if needed.

That order is faster than jumping straight into logs because it separates registration issues from handler failures.