Flow Trigger UI / Kron Schedule MR Deep Dive

TL;DR

• Tracing through how event triggers work: Agent 1486 built an abstracted set of components with configuration props, similar to the item registry pattern
• Triggers have a one-to-one relationship with flows (one trigger per flow), though a flow can have multiple triggers and a trigger type can span multiple flows
• Mapped out the two entry points for trigger configuration: the flow config modal (enable pathway) and the triggers page hierarchy (edit pathway)
• Explored flow trigger event field components: pipeline events, event actions (merge request/work item with sub-events), and schedule events
• Traced parsing utilities in Duo Agent Platform utils.js for schedule config validation, frequency fields, minute value randomization for load distribution, and time zone handling still to review

Understanding Trigger Architecture

Working through this MR, I’ve been digging into how event triggers work and how the code is structured. Agent 1486 did an amazing job creating an abstracted set of components that receive configuration props, similar to what we have with the item registry, but for event triggers. Event triggers can be applied to flows (a type of item), which creates a nesting situation. We have a flow triggers page, but it doesn’t fully make sense yet since triggers and flows currently have a one-to-one relationship - each trigger is associated with exactly one flow, though a flow can have multiple triggers, and a trigger type can be associated with multiple flows.

Two Configuration Entry Points

The trigger configuration page shows up in two places. First, when you go to an existing flow and click enable, a flow config modal comes up letting you select from a list of triggers (mention, assign, assign reviewer, pipeline events, merge request changes, work items) via multi-select. Some triggers have sub-event types - merge request events have approved/merge conflict, work items have created/status changed, and pipeline events have running/passed/failed/canceled. That’s the only place this modal appears. Editing from the flow screen, however, drops you into the triggers page hierarchy instead - so creating/enabling happens in the flows page hierarchy, while editing happens in the triggers page hierarchy.

Component Structure for Trigger Events

Flow trigger events are standalone entities exposed by the backend but always associated with a flow, defined in a static list in the flow trigger events field component - pipeline hooks, merge request, work item, and schedule (newly added). Each configuration returns a component to render. Pipeline events and event configurations are cards with a header and a form group containing a collapsible list box. Event actions configuration handles merge request and work item configs since those have sub-events (on ready, merged, created, status change, etc). Traced through the flow triggers table, the edit/delete buttons, the edit route fetching the flow trigger by ID, and the flow trigger form (built by Agent 1486), which renders the flow trigger events field - shared between the modal and the triggers page forms. Confirmed that the AI catalog item consumer modal consumes the flow trigger events field, getting its data from the flow via the show page and item registry.

Schedule Config Parsing Logic

Traced through the core of the MR: a parsing utility added in Duo Agent Platform utils.js to translate the JSON filter stored on the backend into something usable on the front end. Parse schedule config grabs the schedule key from the filter. Is schedule config valid checks what’s inside the schedule key (which could be null) and gets frequency fields, checking that every field has a valid subfield. Is schedule field valid maps specific frequency selectors against values - e.g., minute values are randomized for load distribution (defined in constants as 0, 15, 30, 45) so triggers don’t all fire at once, and day of month maxes out at 28. Noted this as something to flag on the MR. Also observed that the value int is a placeholder for an enum on the backend mapping schedule/cron job type to an integer, controlled via a GL feature check currently set to false since it’s not yet available on the backend. This trigger’s schedule config sits under its own ‘schedule’ key rather than under the rules field like cron. Still need to look at time zone handling.