### Summary Flow triggers configured for the `pipeline_hooks` event type never fire, no matter what the filter says. Project webhooks with custom filters on pipeline events have the same problem. <details> <summary>Root cause</summary> Commit https://gitlab.com/gitlab-org/gitlab/-/commit/ce9701f82266 added a guard to `Gitlab::FilterEvaluator.dig_value` at `lib/gitlab/filter_evaluator.rb:54`: ``` unless value.is_a?(Hash) ... break ``` The pipeline hook payload comes from `Gitlab::DataBuilder::Pipeline.build(pipeline)` (`app/services/ci/pipelines/hook_service.rb:30`). That class is a `SimpleDelegator` wrapping a plain hash (`lib/gitlab/data_builder/pipeline.rb:7`). Ruby's `Delegator` does not forward `is_a?`, so `SimpleDelegator.new({}).is_a?(Hash)` returns `false`. Because of this, `dig_value` breaks out on the very first path segment (`object_attributes`). The resolved value becomes `nil`, so `["failed"].include?(nil)` is `false`. Every `eq`/`in` rule against a pipeline payload becomes unsatisfiable, and every `ne`/`not_in` rule matches everything. Before the commit, the code called `value['object_attributes']` directly, which the delegator forwarded correctly. Call path: `Ci::Pipelines::HookService#execute` → EE override `execute_flow_triggers` (`ee/app/services/ee/ci/pipelines/hook_service.rb:29`) → `Ai::FlowTriggers::EventTriggerService` → `Ai::FlowTriggers::FilterEvaluator#allowed?` (`ee/app/services/ai/flow_triggers/filter_evaluator.rb:16`) → `Gitlab::FilterEvaluator.evaluate`. </details> ### Steps to reproduce 1. On master at commit c80e1b179f49 (or later, still containing the bug), create an active AI flow trigger with `event_types` including `pipeline_hooks` (value `3`). 2. Set its filter to `{"pipeline_hooks":{"rules":[{"field":"object_attributes.status","operator":"in","value":["failed"]}]}}`. 3. Make sure the trigger's consumer has an active service account. 4. Fail a pipeline in the project. 5. Check for a new `Ai::DuoWorkflows::Workflow` record. None is created. Rails console reproduction, without a real pipeline: ```ruby Gitlab::FilterEvaluator.evaluate( { 'rules' => [{ 'field' => 'object_attributes.status', 'operator' => 'in', 'value' => ['failed'] }] }, Gitlab::DataBuilder::Pipeline.build(Ci::Pipeline.failed.last) ) # => false Gitlab::FilterEvaluator.evaluate( { 'rules' => [{ 'field' => 'object_attributes.status', 'operator' => 'in', 'value' => ['failed'] }] }, Gitlab::DataBuilder::Pipeline.build(Ci::Pipeline.failed.last).__getobj__ ) # => true ``` ### What is the current *bug* behavior? No flow session is created when a pipeline fails, even though the trigger and filter are configured correctly. Nothing is logged at error level. `Gitlab::FilterEvaluator` logs a debug line: `"Filter rule path segment not traversable, rule will not match"` with `stopped_at: object_attributes`. This also blocks the Fix Pipeline foundational flow (`fix_pipeline/v1`). Its precondition `object_attributes.status eq failed` (`ee/app/models/ai/catalog/foundational_flow/fix_pipeline/definition.rb:48-53`) is ANDed into every evaluation, so it can never fire. It also affects project webhooks with custom filters on pipeline events, since `Project#execute_hooks` passes the same delegator to `Projects::TriggeredHooks#execute` (`app/models/projects/triggered_hooks.rb:21`). `Integrations::ExecuteWorker` is not affected, because its data arrives Sidekiq-serialized as a plain Hash by the time it reaches the evaluator. None of the existing specs catch this, because every spec on this chain feeds a plain Hash instead of the real delegator-wrapped payload: - `ee/spec/services/ee/ci/pipelines/hook_service_spec.rb:18` stubs `Gitlab::DataBuilder::Pipeline.build` to return `{}`. - `ee/spec/services/ai/flow_triggers/filter_evaluator_spec.rb:45` uses a literal hash. - `ee/spec/services/ai/flow_triggers/event_trigger_service_spec.rb:124-166` stubs `Gitlab::FilterEvaluator.evaluate`. - `spec/lib/gitlab/filter_evaluator_spec.rb` has no case where the top-level data is not a Hash. ### What is the expected *correct* behavior? Filters on `pipeline_hooks` triggers should evaluate correctly against the pipeline hook payload, and the matching flow session should be created when a pipeline fails and the filter matches. Project webhook filters on pipeline events should behave the same way. ### Relevant logs and/or screenshots Debug log line from `Gitlab::FilterEvaluator` when the bug triggers: ``` Filter rule path segment not traversable, rule will not match, stopped_at: object_attributes ``` No error-level log is produced. ### Possible fixes Change the guard at `lib/gitlab/filter_evaluator.rb:54` from `value.is_a?(Hash)` to a duck-typed check, `value.respond_to?(:key?)`. This is true for a Hash and for a `SimpleDelegator` wrapping a Hash, and false for `String`, `nil`, `Integer`, `Array`, and a `SimpleDelegator` wrapping any of those. This preserves the intent of the original guard (a missing path segment should fail only that rule) and needs no changes at the call sites. Add regression specs: - A delegator-payload case in `spec/lib/gitlab/filter_evaluator_spec.rb`. - A case in `ee/spec/services/ai/flow_triggers/filter_evaluator_spec.rb` that uses the real `Gitlab::DataBuilder::Pipeline` payload of a failed pipeline against an `in ["failed"]` filter. Separate, pre-existing issue, not to be fixed here: `value[key] || value[key.to_sym]` at `lib/gitlab/filter_evaluator.rb:64` treats a legitimate `false` value as missing. This means a rule like `object_attributes.default_branch eq false` can never match.