Cron Trigger Schedule/UI MR Deep Dive

TL;DR

• Traced through Agent 1486’s abstracted components for event triggers, which mirror the item registry pattern but for triggers on flows
• Mapped out the relationship: each trigger is tied to exactly one flow, though a flow can have multiple triggers and trigger types can repeat across flows
• Documented the two entry points for trigger configuration: the flow enable modal and the separate triggers page hierarchy for editing
• Traced flow trigger events field, event actions configuration, and how pipeline/merge request/work item/schedule events each render their own component
• Reviewed new parsing utilities (parse schedule config, is schedule config valid, is schedule field valid) for translating backend JSON filter into frontend schedule config, including minute value distribution (0,15,30,45) and day-of-month max of 28

Understanding the Trigger Architecture

I’m now working through this MR to understand how the event triggers work and how the code is structured. Agent 1486 did an amazing job here; he created an abstracted set of components that receive configuration props, much like we have with the item registry, but for event triggers. Event triggers can be applied to flows, which are a type of item, so there’s a nesting situation. We also have a flow triggers page, but it doesn’t fully make sense yet because we can’t freely apply an independently configured trigger to multiple flows — they currently have a one-to-one relationship. For each trigger there is exactly one flow, although a flow can have multiple triggers, and a trigger type can be associated with multiple flows but only one instance per flow.

Two Entry Points for Configuration

The trigger configuration page shows up in two places. One is when you go to an existing flow and enable it, which brings up a flow config modal where you can select from a list of triggers like mention, assign, assign reviewer, pipeline events, merge request changes, and work items in a multi-select. Some triggers have sub-event types: merge request has approved and merge conflict; work items has created and status changed; pipeline events has running, passed, failed, and canceled. Creating or enabling a flow is done from within the flows page hierarchy, but editing a trigger from the flow screen actually dumps you into the triggers page hierarchy instead.

Event Configuration Components

Flow trigger events are essentially stand-alone 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 schedule events are rendered as cards with a header and a collapsible list box form group. Event actions configuration handles merge request and work item events specifically, since they have sub-events like ‘on ready,’ ‘merged,’ ‘created,’ and ‘status change.’

Tracing the Form Hierarchy

I traced where the flow trigger events field is consumed. In the flow triggers page hierarchy there’s an index with mutations including a delete AI flow trigger mutation, a query to get all flow triggers, a new trigger button, and a flow triggers table with edit and delete buttons. Clicking edit navigates to an edit route with the item’s GraphQL ID, fetching the flow trigger and rendering the flow trigger form. I initially assumed the modal rendered the entire form, but the modal actually has its own form and only renders the flow trigger events field as a child component — that’s where the two come together. In the AI catalog item consumer modal, the flow trigger events field gets its data from the flow via the show page, all configured through the item registry. The flow trigger form (built by Agent 1486) controls creating and editing flow triggers and shares the flow trigger events field between the modal and the triggers page. It receives selected event types, which can be empty for a new form, along with set event types and update filter handlers.

Frontend Schedule Parsing Utilities

I traced the core of the MR: a parsing utility added in the Duo Agent Platform utils.js file to translate the JSON filter stored on the backend into something usable on the frontend. Parse schedule config takes the filter and grabs the schedule key. Is schedule config valid checks what’s inside the schedule key for a frequency definition and its fields, returning false if fields are missing, and otherwise checking each field’s validity via is schedule field valid, which maps frequency selectors like minute against defined values. Minute values are defined in constants as 0, 15, 30, and 45, apparently for load distribution so triggers don’t all fire at once. Scheduled day of month has a max of 28. Noted this as something to flag in the MR. Also noted that schedule frequency uses a GL feature check to control availability (currently false since it’s controlled on the frontend ahead of a backend issue), and that this schedule event, unlike cron which sits in its own array, is nested under ‘schedule’ rather than under the rules field, requiring some duplicate value mapping on the frontend.