Redesign messaging adapter base with caller-resolves pattern
What does this MR do and why?
Establishes the "caller resolves, adapter delivers" pattern for the messaging adapter base class. Callers build a TriggerBundle with fully resolved params, and adapters handle only delivery and lifecycle — no policy, no resolution.
This is stacked on !236476 (merged) which refactors ExecuteWorkflowService to accept pre-resolved flow params.
Key changes
Adapters::Base— rewritten.trigger(bundle)accepts aTriggerBundlevalue object. Tiered resilience (must {}/safe {}), composite identity linking, SA membership, callback context enrichment. Abstract methods useGitlab::AbstractMethodError.CallbackWorker— descendants-based adapter registry replaces hardcoded hash. Per-hooksafe {}isolation.on_flow_failedpassesworkflow:kwarg.TriggerFlowService— deleted. No production callers (only consumer was unmerged !232441 (closed)).
No concrete adapters yet, no new production code paths, no feature flag needed.
References
- Stacked on: !236476 (merged)
- Design: #599691 (closed)
- ADR 008:
gitlab-com/content-sites/handbook!19714 - Previous stack (superseded): !235308 (closed), !235310 (closed), !235039 (closed)
- Flow versioning: !235204 (merged)
- Epic: #590434
How to set up and validate locally
This MR adds no new production code paths. Validate via specs:
bundle exec rspec \
ee/spec/services/ai/messaging/adapters/base_spec.rb \
ee/spec/workers/ai/messaging/callback_worker_spec.rbMR 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 Thomas Schmidt