## Summary A custom Duo flow triggered on a merge request receives `context:goal` as a bare numeric IID. The value does not identify the resource type. When the same IID exists as both an issue and a merge request in the project, the flow can resolve the IID to the wrong object and perform reads and writes there. This was reproduced on GitLab 19.2.4-ee Self-Managed with Duo Self-Hosted by the customer. A flow triggered on merge request `!23` resolved issue `#23`, reviewed the issue, and posted its review note on the issue. The merge request received no note. This is a resource-integrity issue: the run reports success while acting on an object that the trigger did not identify. ## Environment * GitLab 19.2.4-ee, Self-Managed * GitLab Duo Self-Hosted * Flow type: custom Flow * Trigger: assign the flow service account to a merge request * Flow input: ```yaml inputs: - from: "context:goal" as: "source" ``` ## Steps to reproduce 1. In a project, create or retain an issue and a merge request with the same IID, for example issue `#23` and merge request `!23`. 2. Configure a custom flow that receives `context:goal` and resolves the target using the project ID plus the supplied IID. 3. Give the flow permission to read the target and post a note. 4. Assign the flow service account to merge request `!23`. 5. Inspect the flow session and the notes on both resources. ## Actual behavior The trigger supplies a bare value such as `23`. The flow has no type information and resolves the value as issue `#23`. Observed reproduction: * Trigger resource: merge request `!23`, created at `2026-09-02 14:29:22` * Resource resolved by the flow: issue `#23`, created `2026-07-27` * Resources read: `docs/specs/index.md`, `docs/specs/book-search.md`, `backend/internal/store/book_store.go`, and `AGENTS.md` * Write performed: one review note on issue `#23` at `14:30:28` * Merge request `!23`: no note received The flow's closing message explicitly stated that the note had been posted to issue `#23`, even though the trigger was on merge request `!23`. ## Expected behavior The trigger context must preserve the resource type and identity together. For example, it could provide one of: * A typed reference such as `merge_request/23` * The full resource URL * Separate fields such as `context:source_type`, `context:source_iid`, and `context:project_id` * A structured resource object containing `resource_type`, `resource_id`, and `resource_web_url` At minimum, a flow triggered on a merge request must not resolve its goal to an issue. If the resource type cannot be determined, the run should fail before any resource read or write occurs. ## Impact * A flow can read confidential or otherwise unrelated context from the wrong resource. * A flow can write comments or other changes to an object nobody selected. * The session and executor job can report success because the API calls themselves succeed. * The error is silent unless a user manually checks where the resulting note was posted. * Prompt-level heuristics cannot guarantee correctness when issue, work item, and merge request IIDs overlap. ## Related platform behavior The current custom-flow documentation states that Assign and Assign reviewer triggers pass only the resource IID as `context:goal`, including for merge requests. See [Custom flow YAML schema: Goal values by trigger type](https://docs.gitlab.com/user/duo_agent_platform/flows/custom_flows_schema/#goal-values-by-trigger-type). Related upstream work shows the same underlying ambiguity in other flow paths: * [Resolve foundational flow additional context and goal in DAP trigger path (!248388)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/248388) documents a trigger path passing a merge request URL while the flow expected a bare merge request IID. * [Validate the flow-trigger goal for flows that resolve a resource (!252772)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252772) adds trigger-path validation and URL-to-IID normalization for Code Review, but does not provide a general typed resource pointer. * [Bail out of a flow trigger run for an unsupported resource type (#612121)](https://gitlab.com/gitlab-org/gitlab/-/work_items/612121) documents that a flow can start for a resource type it cannot safely handle and proposes failing closed. * [Code Review flow treats goal as merge request IID despite merge_request_id (#610993)](https://gitlab.com/gitlab-org/gitlab/-/work_items/610993) documents the broader problem of overloading `goal` with resource identity. This report is about custom-flow trigger context and is not limited to Code Review. ## Workaround The flow was changed to resolve all possible resource types for the IID and select the object associated with the trigger service account, using recency as a tie-breaker. It exits if the selected object is not the object that triggered the flow. This workaround was verified, however it is heuristic, and is not safe as a platform contract: it fails if the trigger resource is not the most recently touched matching object. ## Proposed fix 1. Add a structured, typed resource reference to the trigger context for every resource-triggered flow. 2. Preserve the trigger resource type through `context:goal` or expose it through separate context fields. 3. Add a platform-side guard that compares the trigger resource type with the flow's supported resource types before dispatch. 4. Fail closed before the first tool call when a flow cannot resolve the trigger resource unambiguously. 5. Add regression coverage where an issue, work item, and merge request share the same IID and the flow is triggered on each resource type. ## Acceptance criteria * A flow triggered on a merge request always reads and writes that merge request, even when issue and work-item IIDs overlap. * A flow triggered on an issue cannot silently resolve the same IID as a merge request. * Unsupported or ambiguous resource types prevent workflow execution and produce an actionable error. * The trigger payload exposes enough information for a custom flow to resolve the exact resource without LLM inference or recency heuristics. * Regression tests cover Assign, Assign reviewer, Mention, and other resource-triggered event types supported by the instance. <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->