Building flows

Lists and items

Many flows work through a list: the morning's exceptions, the tickets in a sprint, the files in a change. A flow process that takes a list runs once per item, each on its own branch, and stored lists make sure the same item is never handled twice.

Every weekday a Sentry step fetches the top errors; each is fixed, reviewed and turned into a pull request on its own.

Make a list

Set an object's How many to *, 1..* or a range, and it holds a JSON array. Lists are drawn as a stack. Here a Sentry process (from Connectors in the sidebar) yields Exceptions, with attributes named after the issue fields it wants: id, shortId, title, culprit, permalink.

Work on each item

Add a flow process
Add a process Each exception taking Exceptions and yielding Outcomes (a list too), and set its Type to Flow.
Zoom in and draw one item's work
Double-click it. Inside, Exceptions is one item. Draw Fix (agent) taking it and yielding Patch, a human Review, and Open PR on approved, yielding Outcomes, which inside is one item of the list outside.
Record each item
Tick Record each time it runs as a run of its own. Each item then runs as a run of its own, listed under the outer run and labelled by what tells the item apart. A failure or duplicate ends only that item's run.

One run per item, in parallel, each on a git branch of its own. What each generates is collected into Outcomes.

Never handle the same item twice

Tick Store what runs generate on Exceptions and mark id Unique. Each item is then claimed by the run that handles it:

On a repeat morning, issues already claimed by a run that is still going or ended done are skipped.
Only runs that end done keep their items, so an issue whose run failed is worked on again next time.
A step that generates a unique value another run already stored is a duplicate: its run ends terminated and its card turns purple, Already processed.

Things to notice

The inner board lists its own objects (Patch, a Developer person); Exceptions and Outcomes are the flow process's interface, drawn dashed, and the inner processes link to them directly.
Each item gets its own branch, so fixes made at once don't meet. See Workspaces and git.
Add an on failure handler to Fix, such as a Report agent that comments on the Sentry issue. It is given what Fix took plus what went wrong.

OPL

Exceptions is a list of items.

Exceptions is stored, so each run keeps what it generated of it.

Fetch is a Sentry process, which fetches issues.

Fetch yields Exceptions.

Each exception is a flow process, made of processes of its own.

Each exception takes Exceptions.

Each exception yields Outcomes.