Add scheduled event type to AI flow triggers

Shola Quadrirequested to merge
594180/sq/flow-triggers-identity-mgmt into master

What does this MR do and why?

MR 2 (of 7) that addressses: #594180

The main change is in ee/app/models/ai/flow_trigger.rb, plus its spec:

  • Registers scheduled: 9 in Ai::FlowTrigger::EVENT_TYPES.
  • Adds the AUTONOMOUS_EVENT_TYPE_IDS constant (currently just the scheduled id).
  • Adds the #autonomous_only? helper. It returns true when event_types is present and every event type is in AUTONOMOUS_EVENT_TYPE_IDS. Nothing calls it yet; later MRs in the stack use it to skip composite-identity enforcement.
  • Adds the scheduled_event_type_available validation. If event_types includes the scheduled id and the autonomous_service_account_execution feature flag is disabled for the trigger's project, it adds the error "scheduled events are not available" on event_types. The flag already exists on master (config/feature_flags/wip/autonomous_service_account_execution.yml, type wip, default disabled) and is the same flag Ai::FlowTriggers::RunService uses for autonomous runs.
  • Adds model specs for the constant, #autonomous_only? (table-driven), the scheduled event type being valid, and the new validation with the flag enabled and disabled.
  • Adds autonomous_only? to scripts/lint/keela_excluded.yml, because the unused-code linter is right: nothing calls the method yet. The MR that adds the first caller will remove the entry again.

GraphQL changes:

  • AiFlowTriggerEventType (ee/app/graphql/types/ai/flow_trigger/event_type_enum.rb) gains a SCHEDULED value, marked experiment: { milestone: '19.4' } because the name or design may still change.
  • AiCatalogTriggerConditionsInput (ee/app/graphql/types/ai/catalog/trigger_conditions_input_type.rb) gains a scheduled argument, also marked experiment for milestone 19.4.
  • Regenerates doc/api/graphql/reference/_index.md and public/-/graphql/introspection_result.json.

The plumbing code is from @squadri. The commit keeps his attribution with a Co-authored-by trailer.

Why this is safe to merge

  • Nothing in the codebase sends a scheduled event. All callers of triggered_on/registered_for? use explicit symbols for other event types. There is no generic dispatcher that could send an event to the new type.
  • AUTONOMOUS_EVENT_TYPE_IDS and autonomous_only? have no callers yet. Later MRs in the stack will use them.
  • Creating a trigger with the scheduled event type through the existing GraphQL mutation only works when autonomous_service_account_execution is enabled for the project. The flag is default-off. Even with the flag on, nothing reads such a trigger, and the service account still gets composite identity enforced by existing, unchanged code. Permissions do not change.
  • The new GraphQL enum value and input argument are marked experimental, so they can be renamed or redesigned without a deprecation cycle.
  • No policy changes, no translated strings, no migrations.

What happened to the old diff

Before, this MR contained the composite identity management code (SyncCompositeIdentityService, two new validations, a policy change, and related wiring). We removed that code from this MR, but it is not lost: it is parked locally. The auth topic returns at the end of the stack, in a new MR that follows the dedicated service account direction from the POC at !251852. The restack was agreed with @eduardobonet.

Note for reviewers: this MR was repurposed. Earlier review comments are about the old identity management diff. They are outdated now.

Related Stacked MRs (in order)

  1. Adds ai_flow_schedules table for scheduled AI f... (!250227 - merged)
  2. Add scheduled event type to AI flow triggers (!250805 - merged) (This MR)
  3. Adds Flow Schedule Model (!250809 - merged)
  4. Add Flow Schedules API (!250821 - merged)
  5. Adds Flow Schedule Email Notifications (!250824 - merged)
  6. Adds flow schedule execution (!250838)
  7. Adds FE changes for Flow Schedules (!250843)

References

Screenshots or screen recordings

Before After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Jessie Young

Merge request reports