Users building custom UIs on Kestra want to search flows, tasks, and executions by a human-friendly name with pattern matching. Most recent ask from Akhil in #help, flagged as recurring, even though I haven't recognized such a request before (screenshot below).
Today IDs have character restrictions and cannot be renamed, descriptions are not searchable via API, and labels only support EQUALS and NOT_EQUALS. Filtering client-side does not scale for executions.
Options
- Extend label operators with
CONTAINS, REGEX, IN. Users put the display name into a reserved label and search it from the API. No schema change.
- Search endpoint over existing fields (
id, description, labels) with CONTAINS or regex. Conflates description with a name for users who write longer prose there.
- Dedicated
displayName field on flows and tasks, plus a search endpoint. Mirrors GitHub Actions where name is mandatory and id optional. Largest workload: new field, migration, and UI decisions about when to show name vs. ID everywhere.
Lean
Option 2 is preferred if we move forward. Option 3 becomes right only if the ask grows beyond what labels can do.
Users building custom UIs on Kestra want to search flows, tasks, and executions by a human-friendly name with pattern matching. Most recent ask from Akhil in #help, flagged as recurring, even though I haven't recognized such a request before (screenshot below).
Today IDs have character restrictions and cannot be renamed, descriptions are not searchable via API, and labels only support
EQUALSandNOT_EQUALS. Filtering client-side does not scale for executions.Options
CONTAINS,REGEX,IN. Users put the display name into a reserved label and search it from the API. No schema change.id,description, labels) withCONTAINSor regex. Conflatesdescriptionwith a name for users who write longer prose there.displayNamefield on flows and tasks, plus a search endpoint. Mirrors GitHub Actions wherenameis mandatory andidoptional. Largest workload: new field, migration, and UI decisions about when to show name vs. ID everywhere.Lean
Option 2 is preferred if we move forward. Option 3 becomes right only if the ask grows beyond what labels can do.