## Why In [!252787](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252787) (Productionise DAP suspendable workloads behind a feature flag), `@fabiopitino` [flagged](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252787#note_3802654394) that the `Ai::DuoWorkflows::` services reach directly into internal `Ci::` implementation details: > :warning: We will have to come back to this design here because the `Ai` module is reaching into internal `Ci` implementation details in these 3 methods below. This is a sign that the boundary between the `ResumeWorkflowService`/`StartWorkflowService` and `Ci` is not clear, leading to this information leak. > > We should open a follow-up issue to refactor these 2 services where `Ai::DuoWorkflows::` components depend on an abstraction provided by `Ci::Workload`. `Ci::Workloads::RunWorkloadService` exists precisely so that callers are insulated from `Ci::Pipeline` semantics ("we abstract users from the underlying `Ci::Pipeline` semantics"). The suspend/resume work punched through that insulation: DAP now walks the pipeline and build graph itself to recover state from a previous run. That coupling means a change to CI's internal models breaks DAP, and every future workload consumer will copy the same traversal. ## What The three methods in `ee/app/services/ai/duo_workflows/resume_workflow_service.rb` that traverse CI internals: ```ruby def previous_workload_variables return {} unless previous_workflow_build previous_workflow_build.yaml_variables.to_h { |v| [v[:key].to_sym, v[:value]] } end def previous_workflow_build @workflow.last_workload&.pipeline&.builds&.order(:id)&.first end strong_memoize_attr :previous_workflow_build def ci_runtime_environment_key previous_workflow_build&.job_runtime_environment&.runtime_environment&.environment_key end ``` Three separate leaks are visible in that chain: 1. **`workload.pipeline.builds.order(:id).first`** — DAP encodes the knowledge that a workload is a pipeline, that it has builds, and that the first one by ID is the relevant job. 2. **`build.yaml_variables`** — DAP reads a CI job's persisted variable format and reshapes it back into a plain hash, having originally handed those variables to CI as a hash. 3. **`build.job_runtime_environment.runtime_environment.environment_key`** — a three-hop association walk across two CI models that exist only to support suspend/resume. `StartWorkflowService` is coupled in the other direction: `#workload_definition` decides `suspend_on_success` / `suspend_on_failure` / `runtime_environment_key`, and `#ci_runtime_environment_key` returns `nil` purely as a hook for the subclass to override. ## How Move the traversal behind an abstraction owned by CI, so DAP asks a workload for what it needs rather than reconstructing it: - Expose the previous run's variables and runtime environment key on `Ci::Workloads::Workload` (or a presenter/query object alongside it) — for example `#variables` and `#runtime_environment_key` — so the `pipeline → builds → job_runtime_environment → runtime_environment` walk lives in `Ci::`, next to the models it depends on. `Workload#logs_url` already does its own `pipeline.builds.order(id: :asc).first` lookup, so a shared "primary job" accessor would remove a duplicate too. - Have `ResumeWorkflowService` call that abstraction, and delete `#previous_workflow_build` from the `Ai::DuoWorkflows::` namespace. - Decide where suspend/resume policy belongs. Passing intent (this workload may be suspended and resumed) into `RunWorkloadService` and letting CI derive the flags reads better than DAP setting three fields on `WorkloadDefinition`, but the `suspendable_environment_for_dap` flag check is DAP's, so the split needs agreeing rather than assuming. - Keep behaviour identical. This is a pure refactor: no change to what is suspended, resumed, or persisted. Worth confirming while doing this whether `Ci::Workloads::Workload` is the right home versus `WorkloadDefinition`, since the definition is the input and the workload is the record of a run. ## Acceptance criteria - [ ] No `Ai::DuoWorkflows::` code references `Ci::Pipeline`, `Ci::Build`, `Ci::JobRuntimeEnvironment` or `Ci::RuntimeEnvironment`, directly or by association traversal. - [ ] The suspend → resume round trip behaves identically with `suspendable_environment_for_dap` enabled, and is unchanged with it disabled. - [ ] Existing specs for `StartWorkflowService`, `ResumeWorkflowService` and `RunWorkloadService` pass without changes to their assertions about observable behaviour. - [ ] The new abstraction is covered by specs in `spec/` (CI-owned), not only through the EE DAP service specs. ## Notes - Blocked on [!252787](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252787) merging. - This is a cross-group change: the callers are owned by ~"group::agent execution" and the abstraction sits in ~"group::ci platform" code (`feature_category: :continuous_integration`). See the comment below on ownership. - Related: [#612876](https://gitlab.com/gitlab-org/gitlab/-/work_items/612876) (the issue !252787 closes), epic [&21874](https://gitlab.com/groups/gitlab-org/-/work_items/21874). <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=628069) </details>